Enrico Weigelt wrote:
* Ciaran McCreesh <[EMAIL PROTECTED]> 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)!
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!
I'm tempted to say "we are not debian" but since I'm not council... :(
Caster
--
gentoo-dev@lists.gentoo.org mailing list
