Enrico Weigelt wrote:
> * Ciaran McCreesh <ciaran.mccreesh@...> schrieb:
> 
> Hi,

Hi Enrico, long time no see!

>> b) Marking that two related implementations are mutually incompatible at
>> runtime because they both provide the same binary.
> 
> Classical example: MTA's:
> 
> Traditionally they tend to provide an /usr/sbin/sendmail executable.
> So you can't have multiple MTAs installed. Here the problem isn't
> that portage can't give more advise, but the system only allows

I see you've been missing this list for a long time. Today it's not
politically correct to say bluntly "portage" but "package manager" (PM)! 
(the kind reader can then usually substitue implementation name 
depending on the e-mail sender)

>> For example, for class d) blocks such as the recent coreutils / mktemp mess, 
> 
> Yes, this is *really* a mess, especially because critical packages are
> involved here.
> 
> IMHO the problem is clearly made by the two packages themselves.
> Actually I didn't track yet who was first, but according to the ebuilds,
> the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp
> should be preferred and the coreutils's one skipped.

Um no, we should not stick with packages forever for historical reasons.

>> the package manager can suggest to the user to install the new package and 
>> then uninstall the old package, rather than forcing the user to uninstall 
>> the old package by hand (possibly leaving their system without critical 
>> utilities) and then install the new package.
> 
> Yes, but this requires the ebuild author to provide enough information 
> *very carefully*.

Yes, ebuild author should be careful, OTOH the end users wouldn't have
to be as much careful as they had to be now when dealing with it themselves.

> In this specific case, portage could automatically 
> decide to replace the separate mktemp package by newer coreutils. 
> But what happens if some package depends on the mktemp package ? 

Such deps should obviously be transformed to || ( >=coreutils-6.10
mktemp) beforehand.

> Portage has to catch these deps and map them to coreutils if they 
> provide mktemp (and only for those versions which *really do*).

No, it should probably just state there's a dep conflict (as it does now
if there are several depends asking for different versions inside one slot).

> This all adds a lot of complexity, and I doubt it's really worth it.

Stating dep conflict should be less complexity, and yes it's worth it.

> Removing mktemp and properly maintaining the standalone package seems 
> much easier and cleaner to me.

Sure, legacy and maintainership burden ftw! Including backporting 
security fixes!
I'm tempted to say "we are not debian" but since I'm not council... :(

Caster