>>>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 
possible.

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 
avoid this.

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.

Any comments?

mortee