1 |
Enrico Weigelt wrote: |
2 |
> * Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> schrieb: |
3 |
> |
4 |
> Hi, |
5 |
|
6 |
Hi Enrico, long time no see! |
7 |
|
8 |
>> b) Marking that two related implementations are mutually incompatible at |
9 |
>> runtime because they both provide the same binary. |
10 |
> |
11 |
> Classical example: MTA's: |
12 |
> |
13 |
> Traditionally they tend to provide an /usr/sbin/sendmail executable. |
14 |
> So you can't have multiple MTAs installed. Here the problem isn't |
15 |
> that portage can't give more advise, but the system only allows |
16 |
|
17 |
I see you've been missing this list for a long time. Today it's not |
18 |
politically correct to say bluntly "portage" but "package manager" (PM)! |
19 |
|
20 |
>> For example, for class d) blocks such as the recent coreutils / mktemp mess, |
21 |
> |
22 |
> Yes, this is *really* a mess, especially because critical packages are |
23 |
> involved here. |
24 |
> |
25 |
> IMHO the problem is clearly made by the two packages themselves. |
26 |
> Actually I didn't track yet who was first, but according to the ebuilds, |
27 |
> the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp |
28 |
> should be preferred and the coreutils's one skipped. |
29 |
|
30 |
Um no, we should not stick with packages forever for historical reasons. |
31 |
|
32 |
>> the package manager can suggest to the user to install the new package and |
33 |
>> then uninstall the old package, rather than forcing the user to uninstall |
34 |
>> the old package by hand (possibly leaving their system without critical |
35 |
>> utilities) and then install the new package. |
36 |
> |
37 |
> Yes, but this requires the ebuild author to provide enough information |
38 |
> *very carefully*. |
39 |
|
40 |
Yes, ebuild author should be careful, OTOH the end users wouldn't have |
41 |
to be as much careful as they had to be now when dealing with it themselves. |
42 |
|
43 |
> In this specific case, portage could automatically |
44 |
> decide to replace the separate mktemp package by newer coreutils. |
45 |
> But what happens if some package depends on the mktemp package ? |
46 |
|
47 |
Such deps should obviously be transformed to || ( >=coreutils-6.10 |
48 |
mktemp) beforehand. |
49 |
|
50 |
> Portage has to catch these deps and map them to coreutils if they |
51 |
> provide mktemp (and only for those versions which *really do*). |
52 |
|
53 |
No, it should probably just state there's a dep conflict (as it does now |
54 |
if there are several depends asking for different versions inside one slot). |
55 |
|
56 |
> This all adds a lot of complexity, and I doubt it's really worth it. |
57 |
|
58 |
Stating dep conflict should be less complexity, and yes it's worth it. |
59 |
|
60 |
> Removing mktemp and properly maintaining the standalone package seems |
61 |
> much easier and cleaner to me. |
62 |
|
63 |
Sure, legacy and maintainership burden ftw! |
64 |
I'm tempted to say "we are not debian" but since I'm not council... :( |
65 |
|
66 |
Caster |
67 |
-- |
68 |
gentoo-dev@l.g.o mailing list |