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] cryptsetup close and device in use when it is not

[Dale]

Frank Steinmetzger wrote:
> Am Wed, Jul 07, 2021 at 01:08:55PM -0500 schrieb Dale:
>
>> root@fireball / # blkid | grep dde669
>> /dev/mapper/8tb: LABEL="8tb-backup"
>> UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
>> root@fireball / # ls /dev/disk/by-uuid | grep dde669
>> 0277ff1b-2d7c-451c-ae94-f20f42dde669
>> root@fireball / #
> I followed this thread, and couldn’t remember ever having the same issue.
> But today I was bitten: It’s a 3 TB external USB drive from Intenso.
>
> Yesterday I was in the middle of a backup (it’s my main backup drive), but I
> had to sleep and so sent the machine into standby. I had to start the PC
> again a few minutes later in order to unmount an sshfs of it on another
> machine, and sent it right back to sleep.
>
> Just now I switched the PC back on and the drive was gone and off (USB
> enclosures tend to spin down the drive when USB disconnects). So I pulled
> the USB cable and plugged it back in for the drive to start and be
> rediscovered. That worked and I resumed the backup, but this enclosure has
> the nasty habit of sometimes intermittently disconnecting on its own.
>
> Its device was not gone (it usually disconnects for a tiny moment and then
> comes back, probably a USB issue), so I just tried to open it again in
> Dolphin, which gave me:
> Error unlocking /dev/sdd1: Failed to activate device: File exists
>
> $ blkid | grep luks
> /dev/mapper/luks-6a55a712-773e-4cd8-9776-fc9b6f39a998: LABEL="backup" 
> UUID="50ed9519-cd9c-4d11-b78a-9f057b089362" BLOCK_SIZE="4096" TYPE="ext4"
>
> $ ls -l /dev/disk/by-uuid/6a55a*
> lrwxrwxrwx 10 root 2021-07-25 21:34 
> /dev/disk/by-uuid/6a55a712-773e-4cd8-9776-fc9b6f39a998 -> ../../sdd1
>
> $ lsblk
> NAME MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
> […]
> sdd8:48   0   2,7T  0 disk
> └─sdd1 8:49   0   2,7T  0 part
>
> $ mount | grep -E 'luks|sdd'
> [nothing]
>
> $ cryptsetup luksClose luks-6a55a712-773e-4cd8-9776-fc9b6f39a998
> Device luks-6a55a712-773e-4cd8-9776-fc9b6f39a998 is still in use.
>
> I don’t quite like this bad habit of the enclosure, but a 3 TB drive is a 3
> TB drive. I just looked at smart to see how old it is, because it has only
> 350 hours of power-on time, but it must be at least 5 years old. And
> smartctl tells me there is a firmware update available! (for Windows, Mac
> and—lo and behold—a bootable ISO, let’s hope it works with USB sticks).
>
> Perhaps this fixes the issue. Dale, maybe you should look for the same.
>


That's interesting.  I have two different drives, can't recall but may
be the same brand.  While using UUID to mount it, it would either fail
every time or in the case of the smaller drive, fail on occasion but not
every time.  The smaller drive worked most of the time but after a
couple failures, I switched to mounting by label.  Since switching both
drives to mount by labels, neither has had a single issue.  My backups
last time went without a hitch.  I was actually planning to post that
after my next backup if nothing failed.  As it is, I think switching to
labels has fixed it. 

I've tried external drives connected by USB before and hated them.  Slow
when they do work and buggy at that.  I've had more drives go bad when
using USB enclosures than I've ever had on IDE or (e)SATA.  I've had two
drives fail after years of service that were IDE or SATA.  I have three
drives that are bricks and all of them were in USB enclosures and far
young to die.  I paid more for eSATA external enclosures and have had no
problems with drives going dead yet.  All of them have far surpassed the
drives in the USB enclosures.  Heck, this 'in use' problem is the first
issue I recall having.  Fast too.  The SMR drive not so much but the CMR
drive is as fast as what is in my system connected to the mobo itself. 

The thing about this, I have no idea why switching to labels works.  The
UUID, label and such are nothing but links to the real device.  It
should make no difference at all which one is used to mount with.  I'm
no guru or anything but it just shouldn't matter. 

Bad thing is, I don't use anything Microsoft here.  Can a drive's
firmware be updated on Linux?  I think my drives are either Seagate or
WD.  I tend to stick with those two, unless it is a really awesome
deal.  I've never updated the firmware on a drive before.  I have my
mobo and my router but not a drive. 

Dale

:-)  :-)

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

[Martin Vaeth]

Alan Mackenzie  wrote:
>
> On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote:
>
>> Portage *cannot* know unless you tell it. The way to tell portage that
>> a package is crucial for *you* is to put it into the world file (or
>> into some set which is in your world file).
>
> OK, so you're clever and you know this. You know to do the
> couter-intuitive thing of putting @system packages into @world.

No, I am doing the intuitive thing, and put *that particular*
service-manager(s) which is crucial for my system in world.

> Less clever people like me follow the handbook, and assume that packages in
> @system are protected.

And they are right to do so. And openrc is not in @system (at least not
in the profile which you have chosen), and certainly the handbook does
not claim the contrary.
Your assumption that all packages which are in stage3 are also in
@system is just plain wrong. It would actually be horrible if that
would be the case.

> Putting init-systems into @world is an unnatural thing to do

No. Putting the packages which *you* want to use into world is
the most natural thing to do. If I would like to run a pure systemd
system or a pure runit system, I would be very unhappy, if I would
be forced to keep openrc, only because some guy decided that the
package manager has to know better what I want than me.

>> The mistake you made is to assume that the profile
>> profiles/default/linux/amd64/17.1/desktop (or whichever profile you
>> use) is an openrc-specific profile. [...]
>
> No, I did not make that mistake.

You did. You would have done the same mistake if you would have
emerged systemd with the same profile without putting it into world,
and have configured your boot-loader to always load systemd:
In that case, systemd would be critical to your system and openrc is
completely superfluous.

Why should you expect that systemd will not get removed in the above
situation if you have not put it into world?
And if you do not expect that: Why should you expect that this is
different for openrc?
Well, you do, because you obviously falsely assumed that you are
using an openrc profile or something similar which let openrc
magically make a "special" package for you in contrast to systemd.

> I simply assumed, not entirely consciously, that Gentoo would not
> destroy my system without me specifically asking it to.

With that logic, portage must *never* unmerge *any* package, as the
systemd example given above shows: After unmerging systemd, the system
gets broken.
Portage is not here to hold your hand. If you make some wrong assumptions
what is in @system, this is *your* problem.

>> One could make also openrc, runit, daemontool profiles, but this
>> would lead to an explosion of the number of profiles (for various
>> architectures and other variants like desktop, hardened, ...),
>> and probably the only thing these profiles would do would be to
>> pull in the init system itself. It is much saner to keep this in
>> the world file.
>
> It would be saner still to be kept in the system file (whatever that
> might be).

Yes, for an openrc profile if it existed. No, for the systemd profile.
And *certainly no* for a more generic profile.

> Fine for a very clever person, not so much for the rest of us.  I
> installed my Gentoo in accordance with the handbook (as of 2017), and I
> don't recall any suggestion of putting critical system packages into the
> world file.

I am sure that there is written something that you should put all
packages which you want to use into the world file. And BTW, I am also
sure that there is nothing written like "do not do this for @system packges".
In fact, the @system set can change and already has changed in the past,
and it is essentially only driven by the needs for a live cd and to
simplify the life of ebuild authors slightly.

> Why not just put ALL system packages into the world file?

The world file is completely your responsibility.
And again, openrc is not a system package (for your profile).
And that the package is critical for *your* setup means nothing.
For other setups the presence of ssh or of some special driver is
crucial. If all these would have to be put into @system, we would
have a very large @system set.
In fact, the aim of @system is to be as small as possible, and its
main intention is that ebuilds need not DEPEND on system packages.
That there are ebuilds which depend on openrc should have given
you a hint already, that openrc is a bad candidate for a @system
package.

>> Except for the warning that you should read *very carefully* through
>> the list of packages which are going to be removed.
>
> That looks more like a "cover your backside" warning than a real warning

This is gentoo - a distribution which explicitly never hinders you to
shoot yourself in the foot. And you really think that if there is even
an explicit warning you should ignore it?

> - one that transfers the responsibility from the perpetrators of an
> unsafe system to the victims.

Oh

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] cryptsetup close and device in use when it is not

[Frank Steinmetzger]

Am Wed, Jul 07, 2021 at 01:08:55PM -0500 schrieb Dale:

> root@fireball / # blkid | grep dde669
> /dev/mapper/8tb: LABEL="8tb-backup"
> UUID="0277ff1b-2d7c-451c-ae94-f20f42dde669" BLOCK_SIZE="4096" TYPE="ext4"
> root@fireball / # ls /dev/disk/by-uuid | grep dde669
> 0277ff1b-2d7c-451c-ae94-f20f42dde669
> root@fireball / #

I followed this thread, and couldn’t remember ever having the same issue.
But today I was bitten: It’s a 3 TB external USB drive from Intenso.

Yesterday I was in the middle of a backup (it’s my main backup drive), but I
had to sleep and so sent the machine into standby. I had to start the PC
again a few minutes later in order to unmount an sshfs of it on another
machine, and sent it right back to sleep.

Just now I switched the PC back on and the drive was gone and off (USB
enclosures tend to spin down the drive when USB disconnects). So I pulled
the USB cable and plugged it back in for the drive to start and be
rediscovered. That worked and I resumed the backup, but this enclosure has
the nasty habit of sometimes intermittently disconnecting on its own.

Its device was not gone (it usually disconnects for a tiny moment and then
comes back, probably a USB issue), so I just tried to open it again in
Dolphin, which gave me:
Error unlocking /dev/sdd1: Failed to activate device: File exists

$ blkid | grep luks
/dev/mapper/luks-6a55a712-773e-4cd8-9776-fc9b6f39a998: LABEL="backup" 
UUID="50ed9519-cd9c-4d11-b78a-9f057b089362" BLOCK_SIZE="4096" TYPE="ext4"

$ ls -l /dev/disk/by-uuid/6a55a*
lrwxrwxrwx 10 root 2021-07-25 21:34 
/dev/disk/by-uuid/6a55a712-773e-4cd8-9776-fc9b6f39a998 -> ../../sdd1

$ lsblk
NAME MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
[…]
sdd8:48   0   2,7T  0 disk
└─sdd1 8:49   0   2,7T  0 part

$ mount | grep -E 'luks|sdd'
[nothing]

$ cryptsetup luksClose luks-6a55a712-773e-4cd8-9776-fc9b6f39a998
Device luks-6a55a712-773e-4cd8-9776-fc9b6f39a998 is still in use.

I don’t quite like this bad habit of the enclosure, but a 3 TB drive is a 3
TB drive. I just looked at smart to see how old it is, because it has only
350 hours of power-on time, but it must be at least 5 years old. And
smartctl tells me there is a firmware update available! (for Windows, Mac
and—lo and behold—a bootable ISO, let’s hope it works with USB sticks).

Perhaps this fixes the issue. Dale, maybe you should look for the same.

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Emacs is a great operating system, which only lacks a good editor.


signature.asc
Description: PGP signature

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

[Rich Freeman]

On Sun, Jul 25, 2021 at 2:05 PM Alan Mackenzie  wrote:
>
> OK, so you're clever and you know this.  You know to do the
> couter-intuitive thing of putting @system packages into @world.  Less
> clever people like me follow the handbook, and assume that packages in
> @system are protected.  Putting init-systems into @world is an unnatural
> thing to do, and must be construed as a workaround for deficiencies in
> portage.

I think you're really conflating the package manager with how some
virtuals/ebuilds are configured.  Portage shouldn't have
service-manager-specific functionality.  Nor should it do things like
never uninstall things that packages say aren't needed just in case
you might still be using them, when you run it with --depclean which
basically is supposed to have it remove the stuff that isn't needed.

All protage does is follow the dependencies.

I think there is room for discussing whether daemontools should be
treated as a service manager by default.  I've never used it and can't
speak to how it is typically used.  You might want to talk to the
maintainers of it to get their thoughts.

> No, I did not make that mistake.  I simply assumed, not entirely
> consciously, that Gentoo would not destroy my system without me
> specifically asking it to.

It isn't like uninstalling openrc is going to "destroy your system".
Worst case you could always just pass init=/bin/bash or whatever to
the kernel and just reinstall it.  Granted, it wouldn't really be
welcome behavior.

> It would be saner still to be kept in the system file (whatever that
> might be).

I suppose you might not care to hear that I've advocated a few times
that the "system file" should disappear entirely and no packages
should get special treatment.  :)  Granted, that has more to do with
how assumed dependencies work in the repository.  I don't really have
a problem with confirmation before removing certain packages because
reinstalling them can be quite painful.  The service manager actually
is one of the easier ones to fix.  If you break the ability to
bootstrap gcc/etc that can be a real bugger to fix.

Really though posting on this list and successfully winning every
argument with everybody who replies is going to do zero to change this
behavior, because it is unlikely that anybody involved in this
particular issue reads this list.  It would make more sense to chat
with the daemontools maintainer and get their thoughts on how the
virtual ought to be configured as a starting point.  You could always
try for a second opinion/etc if that doesn't work.  Plus the
conversation would probably help you understand what their thinking
was.

-- 
Rich

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

[Alan Mackenzie]

Hello, Martin.

On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote:
> Alan Mackenzie  wrote:
> > On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:

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

[  ]

> Portage *cannot* know unless you tell it. The way to tell portage that
> a package is crucial for *you* is to put it into the world file (or
> into some set which is in your world file).

OK, so you're clever and you know this.  You know to do the
couter-intuitive thing of putting @system packages into @world.  Less
clever people like me follow the handbook, and assume that packages in
@system are protected.  Putting init-systems into @world is an unnatural
thing to do, and must be construed as a workaround for deficiencies in
portage.

> The mistake you made is to assume that the profile
> profiles/default/linux/amd64/17.1/desktop (or whichever profile you
> use) is an openrc-specific profile.  It is not: It is the generic
> profile for any init system. And it is a *good* thing that the basic
> profiles do not force an init-system upon you which you do not want to
> use.

No, I did not make that mistake.  I simply assumed, not entirely
consciously, that Gentoo would not destroy my system without me
specifically asking it to.

> The systemd init system has its own profile, but only because systemd
> is not only an init system, and it is therefore natural to have more
> things in that profile than just the init system itself.

> One could make also openrc, runit, daemontool profiles, but this
> would lead to an explosion of the number of profiles (for various
> architectures and other variants like desktop, hardened, ...),
> and probably the only thing these profiles would do would be to
> pull in the init system itself. It is much saner to keep this in
> the world file.

It would be saner still to be kept in the system file (whatever that
might be).

> (Once it has become standard to "combine" profiles from several
> smaller profiles, I would suggest to have such openrc, ... profiles
> as well, but although this is technically possible, already, it is
> hardly documented and certainly cannot be considered at standard.)

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

> > Just as systemd is for your system.

> And for that reason, I have systemd in my world file. (Together with
> openrc, BTW, because I want to be able to toggle between init systems
> for the case that one is not running for whatever reason.)

Fine for a very clever person, not so much for the rest of us.  I
installed my Gentoo in accordance with the handbook (as of 2017), and I
don't recall any suggestion of putting critical system packages into the
world file.  Why not just put ALL system packages into the world file?

> > If you'd installed daemontools you would also have come within
> > a keystroke of destroying your system

> Nope.

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

> Except for the warning that you should read *very carefully* through
> the list of packages which are going to be removed.

That looks more like a "cover your backside" warning than a real warning
- one that transfers the responsibility from the perpetrators of an
unsafe system to the victims.  There is no specific warning that
--depclean can remove critical system files.  Probably there should be.

> Surprises in misconfigured systems can occur. But the problem is
> not the system but the misconfiguration - in your case the missing
> world entry.

Not a bit of it.  The problem is the lack of documentation in the
handbook to perform this counter-intuitive step.

> > No, my problem is caused by Gentoo allowing its package system, without
> > me doing anything strange

> Relying on openrc as a critical part of the system and not telling
> portage about it *is* something strange.

Oh, come on!  Relying on Gentoo not to commit suicide by deleting
critical system packages is strange?  Even you probably started out doing
this when you first installed Gentoo.  There is nothing in the handbook
to say to do this.

> > Nobody here has made any suggestions as to how this situation might be
> > prevented in the future

> The correct suggestion is to inform portage about your intention.
> Maybe add a paragraph to the handbook about doing so (as perhaps
> new users do no even know that they are probably using openrc).
> Gentoo relies on informed users, not on "fixing" things over the
> head of users.

Any system that comes within one keypress of destruction, when the user
hasn't specifically requ

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).

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

[Martin Vaeth]

Neil Bothwick  wrote:
>
> 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.

If you want to solve it by a USE-flag, add this flag to
virtual/service-manager. One could even make it an expand-USE flag,
containing the service manager(s) you want to use. (And have a
restriction that at least one use flag must be selected.)

This has not only the advantage that a re-emerge of a virtual costs
practically no time when you want to change it, you can also say
that you consider more than one service manager crucial for your system.

Actually, not only here but in many || cases some USE-flags would not
hurt.

That being said, the world file has actually exactly the purpose of
informing portage about the packages you want to keep, so doing this
in a virtual is overkill, and actually there is nothing wrong with
the current setup. Maybe more user information in the handbook would
be a good thing. Gentoo relies on informed users.

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

[Martin Vaeth]

Alan Mackenzie  wrote:
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
>
>> 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 is the variable for *your* current init system. Like others have
systemd, runit, or daemontools as *their* current init system.
Portage *cannot* know unless you tell it. The way to tell portage that
a package is crucial for *you* is to put it into the world file
(or into some set which is in your world file).

The mistake you made is to assume that the profile
profiles/default/linux/amd64/17.1/desktop
(or whichever profile you use) is an openrc-specific profile.
It is not: It is the generic profile for any init system. And it is
a *good* thing that the basic profiles do not force an init-system
upon you which you do not want to use.

The systemd init system has its own profile, but only because systemd
is not only an init system, and it is therefore natural to have more
things in that profile than just the init system itself.

One could make also openrc, runit, daemontool profiles, but this
would lead to an explosion of the number of profiles (for various
architectures and other variants like desktop, hardened, ...),
and probably the only thing these profiles would do would be to
pull in the init system itself. It is much saner to keep this in
the world file.

(Once it has become standard to "combine" profiles from several
smaller profiles, I would suggest to have such openrc, ... profiles
as well, but although this is technically possible, already, it is
hardly documented and certainly cannot be considered at standard.)

>> It may be critical for *your* system ... :-)
>
> Just as systemd is for your system.

And for that reason, I have systemd in my world file. (Together with
openrc, BTW, because I want to be able to toggle between init systems
for the case that one is not running for whatever reason.)

> If you'd installed daemontools you would also have come within
> a keystroke of destroying your system

Nope.

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

Except for the warning that you should read *very carefully* through
the list of packages which are going to be removed.

Surprises in misconfigured systems can occur. But the problem is
not the system but the misconfiguration - in your case the missing
world entry.

> No, my problem is caused by Gentoo allowing its package system, without
> me doing anything strange

Relying on openrc as a critical part of the system and not telling
portage about it *is* something strange.

> Nobody here has made any suggestions as to how this situation might be
> prevented in the future

The correct suggestion is to inform portage about your intention.
Maybe add a paragraph to the handbook about doing so (as perhaps
new users do no even know that they are probably using openrc).
Gentoo relies on informed users, not on "fixing" things over the
head of users.

Your suggestion would go into the wrong direction: It means that if
a user install a package which depends on daemontools, and eventually
this dependency gets dropped, or the user removes the package again,
portage would refuse to depclean daemontools, only because it is an
alternative package satisfying a system dependency, and therefore -
according to your suggestion - portage "thinks" that you *might* rely
critically on it without telling portage explicitly that you do so.
It is one of the big advantages of gentoo that it does not have the
"system knows better than the user"-attitude. (Unfortunately, for some
other packages this is not true, but let us not discuss that here.)

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 emerge/po

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