* Ciaran McCreesh <[EMAIL PROTECTED]> schrieb:
Hi,
> 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
one MTA. Portage itself can't help here in any ways - it's all up
to the ebuilds. An clean solution is changing the MTAs to be not
conflicting (using separate filenames, etc) and having some frontend
for these commands, which chooses the right MTA to call on some
configuration.
AFAIK, this is exactly what mailwrapper does :)
Same applies to things like java-config, etc.
> c) Marking that a file that used to be provided by one package is now
> provided by another package that is either depending upon or depended
> upon by the original package.
Do you mean something like this ?
* package foo -> has: /usr/bin/foo
* package bar -> depends: foo
-> has: /usr/bin/foo
> 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.
> 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*. 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 ?
Portage has to catch these deps and map them to coreutils if they
provide mktemp (and only for those versions which *really do*).
This all adds a lot of complexity, and I doubt it's really worth it.
Removing mktemp and properly maintaining the standalone package seems
much easier and cleaner to me.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list
