| 1 |
On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie <acm@×××.de> wrote: |
| 2 |
> |
| 3 |
> On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: |
| 4 |
> > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie <acm@×××.de> wrote: |
| 5 |
> |
| 6 |
> > > So in these virtual packages, it seems by default the _last_ mentioned |
| 7 |
> > > package in a || ( ... ) construct is the one --depclean keeps. It all |
| 8 |
> > > has the feeling of things not having been properly thought through. |
| 9 |
> |
| 10 |
> > I'm not sure what the default is - most likely PMS just requires that |
| 11 |
> > one of them be kept. |
| 12 |
> |
| 13 |
> PMS? Part of emerge? |
| 14 |
|
| 15 |
Package Manager Specification. Specifically: |
| 16 |
https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3 |
| 17 |
|
| 18 |
All it requires is that one be present. Portage can use whatever |
| 19 |
behavior it wishes to decide which to keep (assuming all installed |
| 20 |
packages have their deps). |
| 21 |
|
| 22 |
> It seems it's insisting on removing all packages but one which satisfy a |
| 23 |
> virtual. Maybe that is unwise, and it should keep _all_ such packages |
| 24 |
> which are currently installed. |
| 25 |
|
| 26 |
Well, the whole point of an any-of dependency is to only require one |
| 27 |
of them. Why force packages to stick around if they aren't needed? |
| 28 |
|
| 29 |
Now, whether daemontools actually should satisfy the dependency I |
| 30 |
don't want to comment on without doing more research. Surely though |
| 31 |
there is little point in having openrc and systemd and runit on the |
| 32 |
same system unless the user explicitly wants this (and if they do they |
| 33 |
can just stick them in @world). |
| 34 |
|
| 35 |
> I'm considering submitting a bug to bugs.gentoo.org, requesting that |
| 36 |
> _all_ installed packages satisfying a virtual get kept. There is surely |
| 37 |
> something wrong when somebody who just wants to be a user (me) has to |
| 38 |
> read .ebuild files to get normal things done. |
| 39 |
|
| 40 |
I'd be shocked if that went anywhere. I'd think the better solution |
| 41 |
would be to have some kind of USE flag that tells daemontools whether |
| 42 |
it is used as an actual service manager or not, though that has its |
| 43 |
own issues (changing that state shouldn't require rebuilds/etc, but it |
| 44 |
would). |
| 45 |
|
| 46 |
In any case, you probably should have a chat with the daemontools |
| 47 |
maintainer. I doubt the portage team would consider doing something |
| 48 |
like this as some kind of universal policy. It would impact hundreds |
| 49 |
of things that have any-of dependencies. |
| 50 |
|
| 51 |
-- |
| 52 |
Rich |
Archives