Subject: Re: Changing order of update process
To: None <firstname.lastname@example.org>
From: Marton Fabo <email@example.com>
Date: 12/25/2002 18:25:37
>>>The problem with this was (before buildlink2) that some packages
>>>found their own headers of the installed old version and then had
>>>trouble building -- I guess this is much better now _with_ buildlink2,
>>>but since USE_BUILDLINK2 is not the default for all packages (yet?)
>>>we are not ready to switch the order yet.
> That's not really the obstacle. Even before buildlink, only a handful
> of packages were affected. What's more, if a package is broken in that
> way, anything you to with "make update" doesn't fix it -- plain "make"
> with the old package installed is still going to break, and people are
> still going to complain about that.
Then this clearly seems to be favouring the possibility to use "make
update" (which is considered to be a hack anyway) in the case of those
few packages, over the safety of the update process of every other ones.
Additionally, breaking "make update" in those rare cases would just
require the user to delete and reinstall manually, which would still be
It is clear that in the current situation, simply changing the update
process' order would cause it to fail in case of those few packages,
while making them, because the already existing
headers/libs/executables. I'd have a few suggestion alternatives to
An additional field could be added to those packages that are ready to
be built while another version is installed on the system, to indicate
this. "make update" would check for this field, and refuse to work in
absence thereof, or simply use the old order.
Alternatively, a negative field could be added to the packages that
don't like being built while being also already installed, and this
could be used for a similar purpose as the above field.