| 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 |
Archives