1 |
* Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> schrieb: |
2 |
|
3 |
Hi, |
4 |
|
5 |
> b) Marking that two related implementations are mutually incompatible at |
6 |
> runtime because they both provide the same binary. |
7 |
|
8 |
Classical example: MTA's: |
9 |
|
10 |
Traditionally they tend to provide an /usr/sbin/sendmail executable. |
11 |
So you can't have multiple MTAs installed. Here the problem isn't |
12 |
that portage can't give more advise, but the system only allows |
13 |
one MTA. Portage itself can't help here in any ways - it's all up |
14 |
to the ebuilds. An clean solution is changing the MTAs to be not |
15 |
conflicting (using separate filenames, etc) and having some frontend |
16 |
for these commands, which chooses the right MTA to call on some |
17 |
configuration. |
18 |
|
19 |
AFAIK, this is exactly what mailwrapper does :) |
20 |
|
21 |
Same applies to things like java-config, etc. |
22 |
|
23 |
> c) Marking that a file that used to be provided by one package is now |
24 |
> provided by another package that is either depending upon or depended |
25 |
> upon by the original package. |
26 |
|
27 |
Do you mean something like this ? |
28 |
|
29 |
* package foo -> has: /usr/bin/foo |
30 |
* package bar -> depends: foo |
31 |
-> has: /usr/bin/foo |
32 |
|
33 |
> For example, for class d) blocks such as the recent coreutils / mktemp mess, |
34 |
|
35 |
Yes, this is *really* a mess, especially because critical packages are |
36 |
involved here. |
37 |
|
38 |
IMHO the problem is clearly made by the two packages themselves. |
39 |
Actually I didn't track yet who was first, but according to the ebuilds, |
40 |
the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp |
41 |
should be preferred and the coreutils's one skipped. |
42 |
|
43 |
> the package manager can suggest to the user to install the new package and |
44 |
> then uninstall the old package, rather than forcing the user to uninstall |
45 |
> the old package by hand (possibly leaving their system without critical |
46 |
> utilities) and then install the new package. |
47 |
|
48 |
Yes, but this requires the ebuild author to provide enough information |
49 |
*very carefully*. In this specific case, portage could automatically |
50 |
decide to replace the separate mktemp package by newer coreutils. |
51 |
But what happens if some package depends on the mktemp package ? |
52 |
Portage has to catch these deps and map them to coreutils if they |
53 |
provide mktemp (and only for those versions which *really do*). |
54 |
This all adds a lot of complexity, and I doubt it's really worth it. |
55 |
|
56 |
Removing mktemp and properly maintaining the standalone package seems |
57 |
much easier and cleaner to me. |
58 |
|
59 |
|
60 |
cu |
61 |
-- |
62 |
--------------------------------------------------------------------- |
63 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
64 |
--------------------------------------------------------------------- |
65 |
Please visit the OpenSource QM Taskforce: |
66 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
67 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
68 |
http://patches.metux.de/ |
69 |
--------------------------------------------------------------------- |
70 |
-- |
71 |
gentoo-dev@l.g.o mailing list |