Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Michael Orlitzky]

On Sun, 2021-07-25 at 20:52 -0400, Rich Freeman wrote:
> On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky  wrote:
> > 
> > This is indeed a bug, but not the ones that have been suggested. The
> > underlying problem is that the DJB programs (mail-mta/netqmail, but
> > also net-dns/djbdns, for example) require a particular service manager.
> 
> Is it actually using daemontools as a service manager?  I am not
> familiar enough with it to say.
> 
> When I skimmed the daemontools wiki page I got the impression that it
> was intended to be used in conjunction with openrc.

You start svscan (part of daemontools) with OpenRC, but then you do
some other stuff to make svscan actually start the daemon.


> So, if it is intended as a service manager, it really shouldn't list
> it as a dependency.  After all, we don't go sticking
> openrc/systemd/runit in every package that provides configs for these.

If a service manager is only needed to launch a daemon, then sure. But
the -conf setup programs for djbdns (I don't know about qmail)
create scripts that run executables from daemontools. So unless those
are rewritten or replaced, daemontools is actually needed at runtime.


> 
> > We should have made them support OpenRC and systemd.
> 
> Well, this at least is the subject of a Council decision: no package
> has to support ANY service manager, nor can package maintainers block
> adding support for service managers to a package.
> 

It may be legal to ship a package that's useless out-of-the-box, but
I'm gonna consider it a bug =)

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky  wrote:
>
> This is indeed a bug, but not the ones that have been suggested. The
> underlying problem is that the DJB programs (mail-mta/netqmail, but
> also net-dns/djbdns, for example) require a particular service manager.

Is it actually using daemontools as a service manager?  I am not
familiar enough with it to say.

When I skimmed the daemontools wiki page I got the impression that it
was intended to be used in conjunction with openrc.  Or at least that
is one way it can be used.  Of course, if this is the case it
shouldn't be in that virtual, or if it is then it should itself pull
in openrc as a dependency (assuming it can't also be used with
systemd).

I'd have to spend a lot more time than I care to looking into
daemontools to really comment on that.

> When OpenRC is installed only as a side effect of being listed first in
> virtual/service-manager, it becomes "redundant" after one of the DJB
> programs pulls in daemontools, and portage will offer to remove OpenRC.

So, if it is intended as a service manager, it really shouldn't list
it as a dependency.  After all, we don't go sticking
openrc/systemd/runit in every package that provides configs for these.

> We should have made them support OpenRC and systemd.

Well, this at least is the subject of a Council decision: no package
has to support ANY service manager, nor can package maintainers block
adding support for service managers to a package.

Obviously at this point most packages support openrc/systemd, but they
aren't actually required to.

> With all of that said, maybe in the Handbook we should tell OpenRC
> users to "emerge openrc", in case some other not-mutually-exclusive
> init system is ever pulled in by another program.

So, packages shouldn't be pulling in service managers in general.
That would be a bug if it is the case.  If daemontools does things
other than service management then it might not be an issue, but of
course in that case we probably do need to be careful about treating
it as a service manager automatically.

If a package happens to only supply a systemd service unit then it
shouldn't just pull in systemd because obviously anybody who uses the
package must want to reconfigure their entire host...

It isn't unheard of to have packages that happen to only support one
service manager (though much less common now) - these pacakges should
never just list that service manager as a dependency.  After all,
users can just add their own service units/init.d's/whatevers.

I don't want to say that qmail shouldn't list daemontools without
knowing more about the situation, but that is why I suggested talking
to the maintainer as a first step...

-- 
Rich

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Michael Orlitzky]

(Replying nowhere in particular)

This is indeed a bug, but not the ones that have been suggested. The
underlying problem is that the DJB programs (mail-mta/netqmail, but
also net-dns/djbdns, for example) require a particular service manager.
When OpenRC is installed only as a side effect of being listed first in
virtual/service-manager, it becomes "redundant" after one of the DJB
programs pulls in daemontools, and portage will offer to remove OpenRC.

That's not really a problem with @system or virtual/service-manager. On
a distribution where users are supposed to be able to choose their init
systems, a package that requires one specific init system is just a bad
fit -- for exactly this reason. So in my view, it's a bug in
djbdns/qmail. We should have made them support OpenRC and systemd.

I am halfway responsible for this, since I maintain djbdns and have
never figured out a way to make it work with OpenRC (which would
prevent it from pulling in daemontools, which would prevent --depclean
from trying to remove OpenRC). But, as the maintainer of djbdns, I can
let you in on a secret: don't use djbdns. And if you're not already
heavily invested in qmail, postfix is better in every way.

There's no upstream for these packages so you're unlikely to see any of
this fixed, especially when there are better alternatives.

With all of that said, maybe in the Handbook we should tell OpenRC
users to "emerge openrc", in case some other not-mutually-exclusive
init system is ever pulled in by another program.

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

On Sun, 25 Jul 2021 17:25:17 +, Alan Mackenzie wrote:

> The number of people who would lose their systems by this mechanism is
> likely very small, but that loss would probably involve a
> re-installation.  I mean all a victim has to go on is the fact that his
> machine won't boot, combined with a memory of having run emerge
> --depclean the night before.

So boot into busybox or a rescue disk, look in emerge.log to see what
changed and undo it. I think a "Can't find init" message would be fairly
easy to understand.

> > It seems that Rich's suggestion has the most merit, add a USE flag to
> > daemontools to indicate that it is intended to be your service
> > manager, and have the virtual require that flag. Yes, it would
> > require a one-off rebuild of daemontools for everyone with it
> > installed, but the potential for breakage would be removed.  
> 
> Another idea I had today is to have two packages, daemontools and
> daemontools-init, which would be identical, apart from the fact that
> only the second of these would satisfy virtual/service-manager.

See below.

> I can't help feeling that maybe portage has become too complicated.

See above.

Actually, this has little to do with portage, which s doing exactly what
you told it to do - remove all unnecessary/unwanted packages. The problem
is in your configuration that tells portage that openrc is not needed. If
you want a simple, clean and reasonably permanent solution that doesn't
involve putting openrc in @world, copy the virtual to your local overlay
and remove the daemontools dependency.


-- 
Neil Bothwick

Bus: (n.) a connector you plug money into, something like a slot machine.


pgpy9NDOL6Ami.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Neil.

On Sun, Jul 25, 2021 at 16:40:23 +0100, Neil Bothwick wrote:
> On Sun, 25 Jul 2021 13:43:46 +, Alan Mackenzie wrote:

> > > It may be critical for *your* system ... :-)  

> > Just as systemd is for your system.  If you'd installed daemontools you
> > would also have come within a keystroke of destroying your system, just
> > as I did, on attempting emerge --depclean.  You would have received no
> > warning of any kind on installing the package, and there would be no
> > documentation brought to your attention about the potential catastrophe.

> This is a valid point, that appears to have been obscured by some of the
> discussions about the cause. As to whether it would render the system
> unbootable, I have no idea, would daemontools have taken care of that.

And this is the main point of my complaint - the surprise, the shock, and
the innocence (as in opposite of guilty, not of wordly-wise) of the
victims.  They have done nothing but installing a package in the normal
way.  daemontools can only boot a system if it's been configured to do
so.  That involves writing entries into /etc/inittab.

The number of people who would lose their systems by this mechanism is
likely very small, but that loss would probably involve a
re-installation.  I mean all a victim has to go on is the fact that his
machine won't boot, combined with a memory of having run emerge
--depclean the night before.

My guess (for which I have little basis) would be that daemontools is
used more as part of the various qmail variants rather than as the prime
init system.  I don't recall anybody on this list using d. rather than o.
or s. as their main init system.  In fact, I wasn't even aware it was
possible, before looking it up on Wikipedia this afternoon.

> It seems that Rich's suggestion has the most merit, add a USE flag to
> daemontools to indicate that it is intended to be your service manager,
> and have the virtual require that flag. Yes, it would require a
> one-off rebuild of daemontools for everyone with it installed, but the
> potential for breakage would be removed.

Another idea I had today is to have two packages, daemontools and
daemontools-init, which would be identical, apart from the fact that only
the second of these would satisfy virtual/service-manager.

> If I had to allocate blame for this, I would say it is the virtual that
> is the cause of the problem. With the current setup, unmerging openrc is
> the only way for depclean to deal with it when you have daemontools in
> @world.

I can't help feeling that maybe portage has become too complicated.

> -- 
> Neil Bothwick

> Top Oxymorons Number 41: Good grief

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

On Sun, 25 Jul 2021 13:43:46 +, Alan Mackenzie wrote:

> > It may be critical for *your* system ... :-)  
> 
> Just as systemd is for your system.  If you'd installed daemontools you
> would also have come within a keystroke of destroying your system, just
> as I did, on attempting emerge --depclean.  You would have received no
> warning of any kind on installing the package, and there would be no
> documentation brought to your attention about the potential catastrophe.

This is a valid point, that appears to have been obscured by some of the
discussions about the cause. As to whether it would render the system
unbootable, I have no idea, would daemontools have taken care of that.

It seems that Rich's suggestion has the most merit, add a USE flag to
daemontools to indicate that it is intended to be your service manager,
and have the virtual require that flag. Yes, it would require a
one-off rebuild of daemontools for everyone with it installed, but the
potential for breakage would be removed.

If I had to allocate blame for this, I would say it is the virtual that
is the cause of the problem. With the current setup, unmerging openrc is
the only way for depclean to deal with it when you have daemontools in
@world.


-- 
Neil Bothwick

Top Oxymorons Number 41: Good grief


pgp0ucdbJwt78.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Wols Lists wrote:
> On 25/07/21 14:49, Dale wrote:
>> The problem here is that a user installed a package outside of
>> emerge/portage's knowledge.
> No that does *NOT* appear to be the problem.
>
> The problem is that the user installed - *using* *portage* - a package
> that satisfied a critical system dependency. Except that they did not
> intend for it to satisfy that dependency!
>
> If they HAD installed it outside of portage, they wouldn't have this
> problem.
>
> Cheers,
> Wol
>
>


That is another way of looking at it for sure.  If Alan wants to install
his mail program then maybe he should install the packages it depends on
manually as well.  My point was that emerge/portage has no way of
knowing why he installed daemontools and to emerge/portage, that meant
removing a package that the virtual no longer needed.  To
emerge/portage, having daemontools and openrc installed was no longer
required.  Since he installed daemontools, emerge/portage assumed that
is what he wanted to use.  Since emerge/portage is in the dark as to
why, it's a expected behavior in my opinion. 

Either way, installing packages outside of emerge/portage puts the user
in charge of the problems it creates.  There's several ways to correct
this so maybe one will be attractive enough to Alan to apply.  I like
Neil's myself but to each his own.

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
> Hello, Wol.
>
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
>> On 25/07/21 12:47, Alan Mackenzie wrote:
 They are, @system is a set of packages and nothing it it will be
> depcleaned. However, openrc is not part of @system, the virtual is.
>>> Ah, that's it.  So we have critical system packages which aren't part of
>>> @system.  I think openrc is a critical system package.
>> Well, it's not installed on my new system. I doubt it's installed on any
>> new-ish gentoo-gnome systems. So openrc itself can't be critical.
> Must you be so objectionably pedantic?  It is surely clear that I was
> using "openrc" as a metasyntactic variable for "the current init
> system".  If it wasn't, apologies.
>
>> It may be critical for *your* system ... :-)
> Just as systemd is for your system.  If you'd installed daemontools you
> would also have come within a keystroke of destroying your system, just
> as I did, on attempting emerge --depclean.  You would have received no
> warning of any kind on installing the package, and there would be no
> documentation brought to your attention about the potential catastrophe.
>

Since it had a package left that satisfies the virtual, it shouldn't
warn you.  I don't recall emerge/portage ever warning about removing a
unneeded package other than the warning when you run --depclean and it
first starts.  As said before, this is really expected behavior. 

>> Let's rephrase it - "openrc is one of the (optional) packages that
>> satisfied a critical dependency".
> If you must.
>
>> Your problem is caused because you have explicitly installed an
>> alternate package that satisfies the same critical dependency.
> No, my problem is caused by Gentoo allowing its package system, without
> me doing anything strange, to bring my system to within a single
> keystroke of destruction.  That is a bug in any circumstance.  All you
> and most of the others have done is pointed out the mechanisms by which
> this happened, with the implicit assumption that because that's what
> they do, they must be right.  They're not at all right.
>
> Nobody here has made any suggestions as to how this situation might be
> prevented in the future, not just for me, but for the next user who
> needs daemontools.
>
>> Cheers,
>> Wol


But the problem started when you installed a package outside of
emerge/portage.  As I pointed out earlier, since you installed a package
outside of emerge/portage's knowledge, how do you expect it to know you
need both packages?  It's also why I suggested to either create a ebuild
or add the packages your mail program depends on to the world file. 
Neil came up with what I think is a better solution of using sets.  It
sounds like what he is doing so it must work well enough.

What we are saying is this.  When you install a package outside
emerge/portage's knowledge, you have to manage the things it depends on
and the problems that creates.  In your case, daemontools satisfied the
virtual and emerge/portage wanted to remove openrc but it did so because
you installed another package that satisfies that virtual.  If you
hadn't installed the other package that your mail program needs, that
would not have happened.  So, you actually created the conditions that
made emerge/portage think it was OK to remove the package openrc. 
Again, emerge/portage doesn't know you have your mail program installed
or what it depends on.  It has no idea why you need BOTH daemontools and
openrc installed.  Luckily for you, one isn't a blocker for the other or
that is a whole new can of worms.  Also luckily you caught it was about
to remove it as well. 

The lesson from this, when you install a package outside of
emerge/portage and use emerge/portage to install packages it depends on,
you have to be careful of the problems it creates.  You can't expect
emerge/portage to understand what you are doing and why. 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Wols Lists]

On 25/07/21 14:49, Dale wrote:
> The problem here is that a user installed a package outside of
> emerge/portage's knowledge.

No that does *NOT* appear to be the problem.

The problem is that the user installed - *using* *portage* - a package
that satisfied a critical system dependency. Except that they did not
intend for it to satisfy that dependency!

If they HAD installed it outside of portage, they wouldn't have this
problem.

Cheers,
Wol

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

tastytea wrote:
> On 2021-07-25 13:26+0100 Wols Lists  wrote:
>
>> On 25/07/21 12:47, Alan Mackenzie wrote:
 They are, @system is a set of packages and nothing it it will be  
> depcleaned. However, openrc is not part of @system, the virtual
> is.  
>>> Ah, that's it.  So we have critical system packages which aren't
>>> part of @system.  I think openrc is a critical system package.
>>>   
>> Well, it's not installed on my new system. I doubt it's installed on
>> any new-ish gentoo-gnome systems. So openrc itself can't be critical.
>>
>> It may be critical for *your* system ... :-)
>>
>> Let's rephrase it - "openrc is one of the (optional) packages that
>> satisfied a critical dependency". Your problem is caused because you
>> have explicitly installed an alternate package that satisfies the same
>> critical dependency.
> Maybe OpenRC should come pre-recorded into @world on profiles that
> default to it. If I switch to another init system I can explicitly
> uninstall OpenRC. Forgetting to uninstall it is no big deal.
> Accidentally uninstalling it makes my system unbootable.
>


>From my understanding, nothing should be in @world by default.  The bare
necessities are in @system and what the user installs is in @world.  I
haven't downloaded a starge3 tarball in ages to look but I'm pretty sure
the world file comes empty. 

The problem here is that a user installed a package outside of
emerge/portage's knowledge.  At that point, the user is responsible for
making sure what that package depends on is installed, at the correct
version etc etc.  Since emerge/portage has no knowledge of the package,
it can't making decisions about that package or what it depends on. 

Neil did post a good solution tho.  It's easy enough and will at least
tell emerge/portage that the packages are needed even if it doesn't know
why. 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Wol.

On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
> On 25/07/21 12:47, Alan Mackenzie wrote:
> >> They are, @system is a set of packages and nothing it it will be
> >> > depcleaned. However, openrc is not part of @system, the virtual is.

> > Ah, that's it.  So we have critical system packages which aren't part of
> > @system.  I think openrc is a critical system package.

> Well, it's not installed on my new system. I doubt it's installed on any
> new-ish gentoo-gnome systems. So openrc itself can't be critical.

Must you be so objectionably pedantic?  It is surely clear that I was
using "openrc" as a metasyntactic variable for "the current init
system".  If it wasn't, apologies.

> It may be critical for *your* system ... :-)

Just as systemd is for your system.  If you'd installed daemontools you
would also have come within a keystroke of destroying your system, just
as I did, on attempting emerge --depclean.  You would have received no
warning of any kind on installing the package, and there would be no
documentation brought to your attention about the potential catastrophe.

> Let's rephrase it - "openrc is one of the (optional) packages that
> satisfied a critical dependency".

If you must.

> Your problem is caused because you have explicitly installed an
> alternate package that satisfies the same critical dependency.

No, my problem is caused by Gentoo allowing its package system, without
me doing anything strange, to bring my system to within a single
keystroke of destruction.  That is a bug in any circumstance.  All you
and most of the others have done is pointed out the mechanisms by which
this happened, with the implicit assumption that because that's what
they do, they must be right.  They're not at all right.

Nobody here has made any suggestions as to how this situation might be
prevented in the future, not just for me, but for the next user who
needs daemontools.

> Cheers,
> Wol

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Neil Bothwick wrote:
>
> My point is that you are mixing portage and non-portage packages, that's
> why portage is getting confused. I don't know much about daemontools, but
> it seems the sort of package that should not be in @world, but only
> installed as a dependency of something else.
>
> I'm nit suggesting that you should avoid non-portage packages, that may
> be impossible or undesirable, but you should be aware of possible
> consequences. When I need portage to install dependencies to a
> non-portage package, I generally create a set for them, so you could
> create qmail-deps containing both daemontools and openrc and emerge it.
> Then you are safe from either being depcleaned. If you ever decide to
> stop using qmail, you can just unmerge the set and let portage clean up.
>
>

I forgot about the sets option.  That would be another good way to solve
this issue.  It does mean emerge/portage doesn't know why the packages
are needed but it wouldn't remove them because the user told
emerge/portage not too.  That may be better than adding daemontools to
the world file and much easier than creating a ebuild. 

Nice thinking Neil.  :-D 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

On Sun, 25 Jul 2021 11:47:40 +, Alan Mackenzie wrote:

> > > I would say all packages in @system _are_ needed, unless the user
> > > explicitly says otherwise.  
> 
> > They are, @system is a set of packages and nothing it it will be
> > depcleaned. However, openrc is not part of @system, the virtual is.  
> 
> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.

openrc is not necessarily critical, just some sort of service manager.
that's the whole point of a virtual, to handle different use cases and
requirements.

> > That is possible, but it is also possible that this is entirely down
> > to you installing things outside of portage and handling their
> > dependencies manually, creating unwanted side-effects like this.  
> 
> Quite the contrary.  If I'd've stuck to the daemontools I installed from
> a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
> switched to using the portage version that this danger reared its ugly
> head.

My point is that you are mixing portage and non-portage packages, that's
why portage is getting confused. I don't know much about daemontools, but
it seems the sort of package that should not be in @world, but only
installed as a dependency of something else.

I'm nit suggesting that you should avoid non-portage packages, that may
be impossible or undesirable, but you should be aware of possible
consequences. When I need portage to install dependencies to a
non-portage package, I generally create a set for them, so you could
create qmail-deps containing both daemontools and openrc and emerge it.
Then you are safe from either being depcleaned. If you ever decide to
stop using qmail, you can just unmerge the set and let portage clean up.

> > > Maybe the answer is to regard --depclean as a tool for experts only,
> > > since it is capable in ordinary innocent use of rendering a system
> > > unusable.  
> 
> > I feel it's more a case of Gentoo being a system for those that
> > understand what they are doing with the system - with great power
> > comes great responsibility and all that.  
> 
> That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
> will take the same attitude.  Not only can the user shoot himself in the
> foot, but it's Gentoo that provides the gun, innocently wrapped, with a
> "press here" direction on the packaging above a hidden trigger.  Nobody
> accepts any responsibility for preventing accidents.

It wasn't meant to be patronising, but you should be aware of what is
going on. In this case you were because although portage suggested
removing openrc, you sensibly declined the offer.
 
> The implication of what you say is that nobody should use portage
> without understanding every last intricate detail of it.  This doesn't
> feel reasonable.

No, but it is a system that demands a greater level of understanding from
its users than, say, apt or rpm.

> Nobody but me seems to see anything wrong with all this.  It's one thing
> saying users should look after themselves, but surely it's quite another
> thing to provide an obsure mechanism where one's one keypress away from
> destroying ones system.

You could cripple it but not destroy it. It would not be nice, but you
can recover from the accidental removal of openrc or even python.
Fortunately, you don't have to find out exactly how not nice :)


-- 
Neil Bothwick

- How many surrealists does it take to change a light bulb?
- Two: one to hold the giraffe, the other to fill the bathtub with
  lots of brightly colored machine tools.


pgpykLyJBxQD7.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[tastytea]

On 2021-07-25 13:26+0100 Wols Lists  wrote:

> On 25/07/21 12:47, Alan Mackenzie wrote:
> >> They are, @system is a set of packages and nothing it it will be  
> >> > depcleaned. However, openrc is not part of @system, the virtual
> >> > is.  
> 
> > Ah, that's it.  So we have critical system packages which aren't
> > part of @system.  I think openrc is a critical system package.
> >   
> Well, it's not installed on my new system. I doubt it's installed on
> any new-ish gentoo-gnome systems. So openrc itself can't be critical.
> 
> It may be critical for *your* system ... :-)
> 
> Let's rephrase it - "openrc is one of the (optional) packages that
> satisfied a critical dependency". Your problem is caused because you
> have explicitly installed an alternate package that satisfies the same
> critical dependency.

Maybe OpenRC should come pre-recorded into @world on profiles that
default to it. If I switch to another init system I can explicitly
uninstall OpenRC. Forgetting to uninstall it is no big deal.
Accidentally uninstalling it makes my system unbootable.

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpkXNEeQ2rTz.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
> Hello, Neil.
>
> On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote:
>> On Sat, 24 Jul 2021 21:01:34 +, Alan Mackenzie wrote:
> It seems it's insisting on removing all packages but one which
> satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> such packages which are currently installed.  
 Well, the whole point of an any-of dependency is to only require one
 of them.  Why force packages to stick around if they aren't needed?  
>>> I would say all packages in @system _are_ needed, unless the user
>>> explicitly says otherwise.
>> They are, @system is a set of packages and nothing it it will be
>> depcleaned. However, openrc is not part of @system, the virtual is.
> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.
>
 Now, whether daemontools actually should satisfy the dependency I
 don't want to comment on without doing more research.  Surely though
 there is little point in having openrc and systemd and runit on the
 same system unless the user explicitly wants this (and if they do they
 can just stick them in @world).  
>>> The user might be switching between them, doing comparisons.  (No, I
>>> don't know if this is practical.)  I don't know either whether it's
>>> practical to boot Gentoo with just daemontools.  But there are use cases
>>> which require both openrc and daemontools on the same system, so there's
>>> something not quite right about the service-manager ebuild, or emerge.
>> That is possible, but it is also possible that this is entirely down to
>> you installing things outside of portage and handling their dependencies
>> manually, creating unwanted side-effects like this.
> Quite the contrary.  If I'd've stuck to the daemontools I installed from
> a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
> switched to using the portage version that this danger reared its ugly head. 
>
>>> I think that would be solving the wrong problem.  The fact is, it is
>>> easy, far too easy, to shoot yourself in the foot here.  As well as
>>> openrc, --depclean also wanted to remove nano (the editor) for the same
>>> reason.  That might be serious for some people.
>> It did that because you have another suitable editor installed. I don't
>> like nano so I'm happy to install something else that satisfies
>> virtual/editor and let depclean get rid of nano, knowing that it won't do
>> it unless I already have a suitable alternative installed.
>>> Maybe the answer is to regard --depclean as a tool for experts only,
>>> since it is capable in ordinary innocent use of rendering a system
>>> unusable.
>> I feel it's more a case of Gentoo being a system for those that
>> understand what they are doing with the system - with great power comes
>> great responsibility and all that.
> That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
> will take the same attitude.  Not only can the user shoot himself in the
> foot, but it's Gentoo that provides the gun, innocently wrapped, with a
> "press here" direction on the packaging above a hidden trigger.  Nobody
> accepts any responsibility for preventing accidents.
>
> The implication of what you say is that nobody should use portage
> without understanding every last intricate detail of it.  This doesn't
> feel reasonable.
>
> Nobody but me seems to see anything wrong with all this.  It's one thing
> saying users should look after themselves, but surely it's quite another
> thing to provide an obsure mechanism where one's one keypress away from
> destroying ones system.
>
> I'm quite a bit less enthusiastic about Gentoo than I was a few days
> ago.
>
>> -- 
>> Neil Bothwick
>> Caution, an incorrigible punster - don't incorrige.


The point is the same as it always has been.  If you install a package
outside of portage's knowledge, it is on you to make sure any
dependencies are installed and to update the package itself.  Surely you
don't expect emerge/portage to know you installed a package outside its
knowledge and to keep things it depends on by some sort of magic.  When
a user updates using emerge/portage, it can only go by what it knows. 
It can't assume something it has no knowledge of. 

This is why I mentioned creating a ebuild for your mail program and
using emerge to install it.  In the ebuild will be what that software
depends on.  That puts emerge/portage in the know that certain things
are needed and not to remove them.  Unless you do that, or add needed
packages to the world file, emerge/portage will want to remove things it
feels are not needed based on what it knows.  To be honest, this is
expected behavior.  It's the whole point of --depclean. 

In short, this is expected behavior.  If it didn't work this way, then
I'd say there is a bug that needs to be addressed. 

I might add, this is why I try to never install anything outside of
using 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Wols Lists]

On 25/07/21 12:47, Alan Mackenzie wrote:
>> They are, @system is a set of packages and nothing it it will be
>> > depcleaned. However, openrc is not part of @system, the virtual is.

> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.
> 
Well, it's not installed on my new system. I doubt it's installed on any
new-ish gentoo-gnome systems. So openrc itself can't be critical.

It may be critical for *your* system ... :-)

Let's rephrase it - "openrc is one of the (optional) packages that
satisfied a critical dependency". Your problem is caused because you
have explicitly installed an alternate package that satisfies the same
critical dependency.

Cheers,
Wol

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Neil.

On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote:
> On Sat, 24 Jul 2021 21:01:34 +, Alan Mackenzie wrote:

> > > > It seems it's insisting on removing all packages but one which
> > > > satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> > > > such packages which are currently installed.  

> > > Well, the whole point of an any-of dependency is to only require one
> > > of them.  Why force packages to stick around if they aren't needed?  

> > I would say all packages in @system _are_ needed, unless the user
> > explicitly says otherwise.

> They are, @system is a set of packages and nothing it it will be
> depcleaned. However, openrc is not part of @system, the virtual is.

Ah, that's it.  So we have critical system packages which aren't part of
@system.  I think openrc is a critical system package.

> > > Now, whether daemontools actually should satisfy the dependency I
> > > don't want to comment on without doing more research.  Surely though
> > > there is little point in having openrc and systemd and runit on the
> > > same system unless the user explicitly wants this (and if they do they
> > > can just stick them in @world).  

> > The user might be switching between them, doing comparisons.  (No, I
> > don't know if this is practical.)  I don't know either whether it's
> > practical to boot Gentoo with just daemontools.  But there are use cases
> > which require both openrc and daemontools on the same system, so there's
> > something not quite right about the service-manager ebuild, or emerge.

> That is possible, but it is also possible that this is entirely down to
> you installing things outside of portage and handling their dependencies
> manually, creating unwanted side-effects like this.

Quite the contrary.  If I'd've stuck to the daemontools I installed from
a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
switched to using the portage version that this danger reared its ugly head. 

> > I think that would be solving the wrong problem.  The fact is, it is
> > easy, far too easy, to shoot yourself in the foot here.  As well as
> > openrc, --depclean also wanted to remove nano (the editor) for the same
> > reason.  That might be serious for some people.

> It did that because you have another suitable editor installed. I don't
> like nano so I'm happy to install something else that satisfies
> virtual/editor and let depclean get rid of nano, knowing that it won't do
> it unless I already have a suitable alternative installed.

> > Maybe the answer is to regard --depclean as a tool for experts only,
> > since it is capable in ordinary innocent use of rendering a system
> > unusable.

> I feel it's more a case of Gentoo being a system for those that
> understand what they are doing with the system - with great power comes
> great responsibility and all that.

That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
will take the same attitude.  Not only can the user shoot himself in the
foot, but it's Gentoo that provides the gun, innocently wrapped, with a
"press here" direction on the packaging above a hidden trigger.  Nobody
accepts any responsibility for preventing accidents.

The implication of what you say is that nobody should use portage
without understanding every last intricate detail of it.  This doesn't
feel reasonable.

Nobody but me seems to see anything wrong with all this.  It's one thing
saying users should look after themselves, but surely it's quite another
thing to provide an obsure mechanism where one's one keypress away from
destroying ones system.

I'm quite a bit less enthusiastic about Gentoo than I was a few days
ago.

> -- 
> Neil Bothwick

> Caution, an incorrigible punster - don't incorrige.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

On Sat, 24 Jul 2021 21:01:34 +, Alan Mackenzie wrote:

> > > It seems it's insisting on removing all packages but one which
> > > satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> > > such packages which are currently installed.  
> 
> > Well, the whole point of an any-of dependency is to only require one
> > of them.  Why force packages to stick around if they aren't needed?  
> 
> I would say all packages in @system _are_ needed, unless the user
> explicitly says otherwise.

They are, @system is a set of packages and nothing it it will be
depcleaned. However, openrc is not part of @system, the virtual is.

> > Now, whether daemontools actually should satisfy the dependency I
> > don't want to comment on without doing more research.  Surely though
> > there is little point in having openrc and systemd and runit on the
> > same system unless the user explicitly wants this (and if they do they
> > can just stick them in @world).  
> 
> The user might be switching between them, doing comparisons.  (No, I
> don't know if this is practical.)  I don't know either whether it's
> practical to boot Gentoo with just daemontools.  But there are use cases
> which require both openrc and daemontools on the same system, so there's
> something not quite right about the service-manager ebuild, or emerge.

That is possible, but it is also possible that this is entirely down to
you installing things outside of portage and handling their dependencies
manually, creating unwanted side-effects like this.

> I think that would be solving the wrong problem.  The fact is, it is
> easy, far too easy, to shoot yourself in the foot here.  As well as
> openrc, --depclean also wanted to remove nano (the editor) for the same
> reason.  That might be serious for some people.

It did that because you have another suitable editor installed. I don't
like nano so I'm happy to install something else that satisfies
virtual/editor and let depclean get rid of nano, knowing that it won't do
it unless I already have a suitable alternative installed.

> Maybe the answer is to regard --depclean as a tool for experts only,
> since it is capable in ordinary innocent use of rendering a system
> unusable.

I feel it's more a case of Gentoo being a system for those that
understand what they are doing with the system - with great power comes
great responsibility and all that.


-- 
Neil Bothwick

Caution, an incorrigible punster - don't incorrige.


pgpjz1KCrrge_.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Wols Lists]

On 24/07/21 22:09, Alan Mackenzie wrote:
> I'm actually using s/qmail, tarball direct from its maintainer, since
> there's no ebuild for it.  Originally, I had daemontools from the same
> place, until I discovered there was an ebuild for it.

THAT LOOKS LIKE YOUR PROBLEM.

If daemontools has been pulled in because it's explicitly named in
world, then emerge will (quite reasonably) assume that openrc (which is
an implied dependency) can be dispensed with.

In other words, if one member of a virtual package is explicitly
installed, all the other members can be dispensed with. Changing this is
likely to cause breakage all over the place!!!

Okay, it's a nasty surprise to discover that installing a package with
multiple uses can make the system assume you're using it for things
you're not, but I think the only *workable* fix is, as others have said,
to add openrc to the world set.

You've explicitly pulled in a boot manager package. You can't expect
portage to keep a bunch of implicit package managers (systemd, sysV,
openrc etc) lying around when you haven't asked for them. I've installed
postfix as my mailer - I don't want exim, sendmail, etc etc lying around
"just in case".

Cheers,
Wol

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
> Hello, Dale.
>
> On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote:
>
>> Maybe qmail needs a USE flag to pull in daemontools?
> I'm actually using s/qmail, tarball direct from its maintainer, since
> there's no ebuild for it.  Originally, I had daemontools from the same
> place, until I discovered there was an ebuild for it.
>
>

Ahhh.  That could be a issue when filing a bug.  When using something
without the package manager installing it, it usually leaves you on your
own.  The easiest thing may be to just add daemontools to your world
file and leave it at that.  The maintainer may have another solution but
I'm suspecting not. 

Another option, create a ebuild for your mail program and put it in your
overlay.  Then you can use emerge to install your mail program so that
emerge knows the dependencies it needs, including daemontools.  As it
is, it doesn't even know you have the mail program there.  Sort of hard
for emerge/portage to know you need a tool kept around.  A ebuild for it
and using emerge to install it would fix that.  Maybe a USE flag or just
a plain hard requirement for daemontools. 

Just a thought.  Someone else may have a better hammer to fix this
problem. 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Dale.

On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote:
> Alan Mackenzie wrote:

> > I'm considering submitting a bug to bugs.gentoo.org, requesting that
> > _all_ installed packages satisfying a virtual get kept.  There is surely
> > something wrong when somebody who just wants to be a user (me) has to
> > read .ebuild files to get normal things done.



> If you can, I'd recommend trying to reach out to the maintainer to see
> if that is expected behavior.  It could be that that is the way it is
> supposed to work.  If that is so tho, I find it odd.

I find it infuriating when ordinary innocent use of something like
emerge can totally break a system.

> Maybe qmail needs a USE flag to pull in daemontools?

I'm actually using s/qmail, tarball direct from its maintainer, since
there's no ebuild for it.  Originally, I had daemontools from the same
place, until I discovered there was an ebuild for it.

> Maybe something else needs changing.  I'd start by reaching out to the
> maintainer.  I guess a bug report would be considered reaching out but
> a email may also work as well. 

Thanks, I submitted a bug report.  I think it's a bug in emerge.  I've
got a nasty feeling there isn't enough sympathy for non-experts for that
bug to go anywhere, but we'll see.

> Just my thoughts.  May not be worth much.  ;-)

> Dale

> :-)  :-) 

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello again, Rich.

On Sat, Jul 24, 2021 at 10:58:55 -0400, Rich Freeman wrote:
> On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie  wrote:

> > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:

> > > > So in these virtual packages, it seems by default the _last_ mentioned
> > > > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > > > has the feeling of things not having been properly thought through.

> > > I'm not sure what the default is - most likely PMS just requires that
> > > one of them be kept.

> > PMS?  Part of emerge?

> Package Manager Specification.  Specifically:
> https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3

Ah, thanks!

> All it requires is that one be present.  Portage can use whatever
> behavior it wishes to decide which to keep (assuming all installed
> packages have their deps).

> > It seems it's insisting on removing all packages but one which satisfy a
> > virtual.  Maybe that is unwise, and it should keep _all_ such packages
> > which are currently installed.

> Well, the whole point of an any-of dependency is to only require one
> of them.  Why force packages to stick around if they aren't needed?

I would say all packages in @system _are_ needed, unless the user
explicitly says otherwise.

> Now, whether daemontools actually should satisfy the dependency I
> don't want to comment on without doing more research.  Surely though
> there is little point in having openrc and systemd and runit on the
> same system unless the user explicitly wants this (and if they do they
> can just stick them in @world).

The user might be switching between them, doing comparisons.  (No, I
don't know if this is practical.)  I don't know either whether it's
practical to boot Gentoo with just daemontools.  But there are use cases
which require both openrc and daemontools on the same system, so there's
something not quite right about the service-manager ebuild, or emerge.

> > I'm considering submitting a bug to bugs.gentoo.org, requesting that
> > _all_ installed packages satisfying a virtual get kept.  There is surely
> > something wrong when somebody who just wants to be a user (me) has to
> > read .ebuild files to get normal things done.

> I'd be shocked if that went anywhere.  I'd think the better solution
> would be to have some kind of USE flag that tells daemontools whether
> it is used as an actual service manager or not, though that has its
> own issues (changing that state shouldn't require rebuilds/etc, but it
> would).

I think that would be solving the wrong problem.  The fact is, it is
easy, far too easy, to shoot yourself in the foot here.  As well as
openrc, --depclean also wanted to remove nano (the editor) for the same
reason.  That might be serious for some people.

I have, in fact, submitted a bug on the "shoot yourself in the foot"
problem.  So far it's got one reply which (possibly wilfully)
misunderstood the intent of the report, and said, much like you did "add
daemontools to @world and the problem's solved".

Maybe the answer is to regard --depclean as a tool for experts only,
since it is capable in ordinary innocent use of rendering a system
unusable.

> In any case, you probably should have a chat with the daemontools
> maintainer.  I doubt the portage team would consider doing something
> like this as some kind of universal policy.  It would impact hundreds
> of things that have any-of dependencies.

OK.  The suggestion I made in my bug report was that @system packages
should be protected, much like @world packages are already.  I don't see
the rationale in protecting @world, but not the more important @system.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
>
> I'm considering submitting a bug to bugs.gentoo.org, requesting that
> _all_ installed packages satisfying a virtual get kept.  There is surely
> something wrong when somebody who just wants to be a user (me) has to
> read .ebuild files to get normal things done.
>
>

If you can, I'd recommend trying to reach out to the maintainer to see
if that is expected behavior.  It could be that that is the way it is
supposed to work.  If that is so tho, I find it odd.  Maybe qmail needs
a USE flag to pull in daemontools?  Maybe something else needs
changing.  I'd start by reaching out to the maintainer.  I guess a bug
report would be considered reaching out but a email may also work as well. 

Just my thoughts.  May not be worth much.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie  wrote:
>
> On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:
>
> > > So in these virtual packages, it seems by default the _last_ mentioned
> > > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > > has the feeling of things not having been properly thought through.
>
> > I'm not sure what the default is - most likely PMS just requires that
> > one of them be kept.
>
> PMS?  Part of emerge?

Package Manager Specification.  Specifically:
https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3

All it requires is that one be present.  Portage can use whatever
behavior it wishes to decide which to keep (assuming all installed
packages have their deps).

> It seems it's insisting on removing all packages but one which satisfy a
> virtual.  Maybe that is unwise, and it should keep _all_ such packages
> which are currently installed.

Well, the whole point of an any-of dependency is to only require one
of them.  Why force packages to stick around if they aren't needed?

Now, whether daemontools actually should satisfy the dependency I
don't want to comment on without doing more research.  Surely though
there is little point in having openrc and systemd and runit on the
same system unless the user explicitly wants this (and if they do they
can just stick them in @world).

> I'm considering submitting a bug to bugs.gentoo.org, requesting that
> _all_ installed packages satisfying a virtual get kept.  There is surely
> something wrong when somebody who just wants to be a user (me) has to
> read .ebuild files to get normal things done.

I'd be shocked if that went anywhere.  I'd think the better solution
would be to have some kind of USE flag that tells daemontools whether
it is used as an actual service manager or not, though that has its
own issues (changing that state shouldn't require rebuilds/etc, but it
would).

In any case, you probably should have a chat with the daemontools
maintainer.  I doubt the portage team would consider doing something
like this as some kind of universal policy.  It would impact hundreds
of things that have any-of dependencies.

-- 
Rich

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Rich.

On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:

> > So in these virtual packages, it seems by default the _last_ mentioned
> > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > has the feeling of things not having been properly thought through.


> I'm not sure what the default is - most likely PMS just requires that
> one of them be kept.

PMS?  Part of emerge?

It seems it's insisting on removing all packages but one which satisfy a
virtual.  Maybe that is unwise, and it should keep _all_ such packages
which are currently installed.

> If daemontools (or something that depends on it) is in your @world
> that would explain why openrc was selected for removal.

OK, that solves the mystery, thanks.

> I don't know enough to comment on whether daemontools is a substitute
> for openrc.  My first complete guess would be that it could either be
> used in addition to openrc or on its own.

I've only ever used it as part of qmail (the mail transport program),
never on its own.  I'm loathe to mess around with it, since my email
depends on it.  But from what I remember about daemontools, it probably
could be used as an alternative to openrc, I just don't envisage anybody
wanting to do it, though.

> Busybox can be a substitute for sysvinit or udev though most people
> who have it installed probably don't intend for it to be used that
> way.  You could have that conversation with the maintainer.

I'm considering submitting a bug to bugs.gentoo.org, requesting that
_all_ installed packages satisfying a virtual get kept.  There is surely
something wrong when somebody who just wants to be a user (me) has to
read .ebuild files to get normal things done.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:
>
> So in these virtual packages, it seems by default the _last_ mentioned
> package in a || ( ... ) construct is the one --depclean keeps.  It all
> has the feeling of things not having been properly thought through.
>

I'm not sure what the default is - most likely PMS just requires that
one of them be kept.

If daemontools (or something that depends on it) is in your @world
that would explain why openrc was selected for removal.

I don't know enough to comment on whether daemontools is a substitute
for openrc.  My first complete guess would be that it could either be
used in addition to openrc or on its own.  Busybox can be a substitute
for sysvinit or udev though most people who have it installed probably
don't intend for it to be used that way.  You could have that
conversation with the maintainer.

-- 
Rich

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Neil.

On Wed, Jul 21, 2021 at 21:27:05 +0100, Neil Bothwick wrote:
> On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote:

> > > emerge included openrc (the only version of it on my system) in the
> > > packages it planned to remove.  It was kind enough to give me a
> > > warning that this "might" do bad things, but I was somewhat shocked
> > > to see it there at all.  I might have accidentally typed 'y' instead
> > > of 'n'.

> > > Maybe the program wants revenge at me executing so seldomly.  Or
> > > something like that.

> Well, it would help if you ran it more often.

> > > But now, my question is how can I trust --depclean even a little bit
> > > after that?  Do I have to go through all the package versions,
> > > manually removing the obsolete ones?  There are several hundred.  :-(


> > I'm not sure why it would want to remove openrc, as far as I know it
> > should be part of the @system set unless you're on a systemd profile.

> It's the first dependency of virtual/system-manager, which in turn is
> part of @system. I don't see why it would be removed unless you have
> something else installed that satisfies the virtual , such as systemd or
> runit.

The virtual/service-manager ebuild looks like:

;
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Virtual for various service managers"

SLOT="0"
KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 
sparc x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos 
~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt"
IUSE="kernel_linux"

RDEPEND="
prefix-guest? ( >=sys-apps/baselayout-prefix-2.2 )
!prefix-guest? (
|| (
sys-apps/openrc
kernel_linux? ( || (
sys-apps/systemd
sys-process/runit
virtual/daemontools <
) ) ) )"
;

Maybe virtual/daemontools is what's doing it.  I have
sys-process/daemontools-0.76-r8 installed, and this ebuild satisfies
virtual/daemontools.

However daemontools is NOT (necessarily) an alternative to openrc, but a
supplementary utility.  (I need it for running a qmail variant.)  So,
maybe having daemontools in virtual/service-manager is a bug.

Also, why is --depclean keeping the _last_ installed package which
satisfies a virtual rather than the _first_ package which does?  I
thought only a single package satisfying a virtual was allowed.  Maybe I
used some sort of forcing flag to get daemontools installed, I can't
remember, and there's nothing about this in my notes.

I've got a similar situation with virtual/editor, where I've got vim
installed, and --depclean wants to remove nano, but is warning me against
it.

So in these virtual packages, it seems by default the _last_ mentioned
package in a || ( ... ) construct is the one --depclean keeps.  It all
has the feeling of things not having been properly thought through.

> > You can record it in your @world set with `emerge --select --noreplace
> > sys-apps/openrc`. That should prevent accidental removals.

> It would, but it doesn't address the issue of why portage wants to remove
> it.


> -- 
> Neil Bothwick

> mandelbug /man'del-buhg/ n.
>  [from the Mandelbrot set] A
>bug whose underlying causes are so complex and obscure as to make
>its behavior appear chaotic or even non-deterministic.  This term
>implies that the speaker thinks it is a Bohr bug, rather than
>a heisenbug.  See also schroedinbug.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote:

> > emerge included openrc (the only version of it on my system) in the
> > packages it planned to remove.  It was kind enough to give me a
> > warning that this "might" do bad things, but I was somewhat shocked
> > to see it there at all.  I might have accidentally typed 'y' instead
> > of 'n'.
> > 
> > Maybe the program wants revenge at me executing so seldomly.  Or
> > something like that.

Well, it would help if you ran it more often.

> > But now, my question is how can I trust --depclean even a little bit
> > after that?  Do I have to go through all the package versions,
> > manually removing the obsolete ones?  There are several hundred.  :-(
> >  
> 
> I'm not sure why it would want to remove openrc, as far as I know it
> should be part of the @system set unless you're on a systemd profile.

It's the first dependency of virtual/system-manager, which in turn is
part of @system. I don't see why it would be removed unless you have
something else installed that satisfies the virtual , such as systemd or
runit.

> You can record it in your @world set with `emerge --select --noreplace
> sys-apps/openrc`. That should prevent accidental removals.

It would, but it doesn't address the issue of why portage wants to remove
it.


-- 
Neil Bothwick

mandelbug /man'del-buhg/ n.
 [from the Mandelbrot set] A
   bug whose underlying causes are so complex and obscure as to make
   its behavior appear chaotic or even non-deterministic.  This term
   implies that the speaker thinks it is a Bohr bug, rather than
   a heisenbug.  See also schroedinbug.


pgpP4DvBDXCVH.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[tastytea]

On 2021-07-21 20:06+ Alan Mackenzie  wrote:

> Hello, Gentoo.
> 
> As prompted after the recent perl update, I did # emerge --depclean
> -va.
> 
> emerge included openrc (the only version of it on my system) in the
> packages it planned to remove.  It was kind enough to give me a
> warning that this "might" do bad things, but I was somewhat shocked
> to see it there at all.  I might have accidentally typed 'y' instead
> of 'n'.
> 
> Maybe the program wants revenge at me executing so seldomly.  Or
> something like that.
> 
> But now, my question is how can I trust --depclean even a little bit
> after that?  Do I have to go through all the package versions,
> manually removing the obsolete ones?  There are several hundred.  :-(

I'm not sure why it would want to remove openrc, as far as I know it
should be part of the @system set unless you're on a systemd profile.

You can record it in your @world set with `emerge --select --noreplace
sys-apps/openrc`. That should prevent accidental removals.

Kind regards, tastytea

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpwm5jgbCOgs.pgp
Description: Digitale Signatur von OpenPGP