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 |
(the kind reader can then usually substitue implementation name |
20 |
depending on the e-mail sender) |
21 |
|
22 |
>> For example, for class d) blocks such as the recent coreutils / mktemp mess, |
23 |
> |
24 |
> Yes, this is *really* a mess, especially because critical packages are |
25 |
> involved here. |
26 |
> |
27 |
> IMHO the problem is clearly made by the two packages themselves. |
28 |
> Actually I didn't track yet who was first, but according to the ebuilds, |
29 |
> the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp |
30 |
> should be preferred and the coreutils's one skipped. |
31 |
|
32 |
Um no, we should not stick with packages forever for historical reasons. |
33 |
|
34 |
>> the package manager can suggest to the user to install the new package and |
35 |
>> then uninstall the old package, rather than forcing the user to uninstall |
36 |
>> the old package by hand (possibly leaving their system without critical |
37 |
>> utilities) and then install the new package. |
38 |
> |
39 |
> Yes, but this requires the ebuild author to provide enough information |
40 |
> *very carefully*. |
41 |
|
42 |
Yes, ebuild author should be careful, OTOH the end users wouldn't have |
43 |
to be as much careful as they had to be now when dealing with it themselves. |
44 |
|
45 |
> In this specific case, portage could automatically |
46 |
> decide to replace the separate mktemp package by newer coreutils. |
47 |
> But what happens if some package depends on the mktemp package ? |
48 |
|
49 |
Such deps should obviously be transformed to || ( >=coreutils-6.10 |
50 |
mktemp) beforehand. |
51 |
|
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 |
|
55 |
No, it should probably just state there's a dep conflict (as it does now |
56 |
if there are several depends asking for different versions inside one slot). |
57 |
|
58 |
> This all adds a lot of complexity, and I doubt it's really worth it. |
59 |
|
60 |
Stating dep conflict should be less complexity, and yes it's worth it. |
61 |
|
62 |
> Removing mktemp and properly maintaining the standalone package seems |
63 |
> much easier and cleaner to me. |
64 |
|
65 |
Sure, legacy and maintainership burden ftw! Including backporting |
66 |
security fixes! |
67 |
I'm tempted to say "we are not debian" but since I'm not council... :( |
68 |
|
69 |
Caster |