From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 1F8E0158083 for ; Tue, 24 Sep 2024 15:15:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8CE552BC0B9; Tue, 24 Sep 2024 15:15:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 260A92BC03C for ; Tue, 24 Sep 2024 15:15:14 +0000 (UTC) Message-ID: <4219bce4-f14f-4c5d-a52a-a303dd583907@gentoo.org> Date: Tue, 24 Sep 2024 11:15:10 -0400 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!] To: gentoo-user@lists.gentoo.org References: <65e5de50-e053-46ff-be61-52f472d95025@gentoo.org> <2c966cf9-9cc5-4f51-96a4-9c0e537d5f95@gentoo.org> Content-Language: en-US From: Eli Schwartz Autocrypt: addr=eschwartz@gentoo.org; keydata= xjMEZmeRNBYJKwYBBAHaRw8BAQdAYNZ7pUDWhx1i2f3p6L2ZLu4FcY18UoeGC04Gq/khqwfN I0VsaSBTY2h3YXJ0eiA8ZXNjaHdhcnR6QGdlbnRvby5vcmc+wpYEExYKAD4WIQTvUdMIsc4j CIi+DYTqQj6ToWND8QUCZoRL+gIbAwUJBKKGAAULCQgHAwUVCgkICwUWAgMBAAIeBQIXgAAK CRDqQj6ToWND8aB5AP9r4kB691nNtNwKkdRiOdl7/k6WYzokvHvDamXxRJ0I+gEAjZqR5V8y mfR3fy2Z+r2Joeqdt3CIv5IwPs64spBvigLOOARmZ5E0EgorBgEEAZdVAQUBAQdATT46Z06b 1X9xjXFCYFxmq/Tj3tSEKZInDWTpoHQp4l8DAQgHwn4EGBYKACYWIQTvUdMIsc4jCIi+DYTq Qj6ToWND8QUCZmeRNAIbDAUJBKKGAAAKCRDqQj6ToWND8a2RAP40KPfbfoiZAJW5boFmFJ3G TUBDJRh9CWHyaPqq2PN+0wD/R07oLzfnJUN209mzi9TuTuHjeZybysyqXSw4MAxkMAY= In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------RDYua8gLMPuyxvJt3iuhmVjH" X-Archives-Salt: d4524a70-dcbc-41e7-a1eb-17480b837697 X-Archives-Hash: f5f971060a988cad3d65b28ecbc21956 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------RDYua8gLMPuyxvJt3iuhmVjH Content-Type: multipart/mixed; boundary="------------8rM0CAVi7aV8XCVYIfUEuTq9"; protected-headers="v1" From: Eli Schwartz To: gentoo-user@lists.gentoo.org Message-ID: <4219bce4-f14f-4c5d-a52a-a303dd583907@gentoo.org> Subject: Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!] References: <65e5de50-e053-46ff-be61-52f472d95025@gentoo.org> <2c966cf9-9cc5-4f51-96a4-9c0e537d5f95@gentoo.org> In-Reply-To: --------------8rM0CAVi7aV8XCVYIfUEuTq9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9/24/24 7:30 AM, Alan Mackenzie wrote: >> This should not generally be possible. The @system set contains >> virtual/service-manager, so you cannot depclean that. >=20 > It is very much possible, and it happens. The mechanism is understood,= > you've outlined it below. Clearly, since I said it is "generally" not possible, I agree that it is sometimes possible and the mechanism for the sometimes is understood. After all, I did outline it, and you agree with my outline. So why, exactly, are you *arguing* with me, as though you believe I have said it is not possible? Can you point me to where I said it is not possible? I said it's an edge case, not a systematic flaw in Gentoo or portage designed to break people's systems. Edge cases should be reported and fixed, but also edge cases have trivial workarounds which you can carry out: add openrc manually to @world, and it is no longer dangerous to run --depclean as part of regular maintenance of a healthy system. >> It's possible you have installed another one of these packages too. If= >> you do, then virtual/service-manager will still be satisfied, and it >> will allow you to depclean openrc. >=20 > Yes, I have daemontools, needed as a component of a qmail variant. Sigh, djbware strikes again. The fact that daemontools claims to be a service manager, but is needed for random packages WITHOUT being used as a service manager, is alarming and probably broken. >> In theory, one should not have multiple init systems installed. And >> openrc is the preferred satisfier, so if you use `emerge --depclean` i= t >> will try to depclean the other package, not openrc. But you can depcle= an >> openrc itself in that case, since portage doesn't know which init syst= em >> you intend to keep. >=20 > If I had invoked --depclean without the -a (or -p) flag, my system woul= d > have had openrc removed, and it would have been unbootable. This is th= e > sort of thing a new Gentoo user might do. >=20 >> Even in this case it emits a warning: >=20 >> !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system= >> profile. >> !!! Unmerging it may be damaging to your system. >=20 > So, having your system made unbootable is opt-out rather than opt-in. That is a severely unkind interpretation of what I said, and of what portage does. Also, installing daemontools isn't the kind of thing a new Gentoo user might do. Nor is installing qmail. >> to make sure you are fully aware that you intend to depclean a package= >> that *might* be the wrong one. >=20 > The context of this discussion was an implication that the Gentoo > maintainers wouldn't make a change "that made everyone's systems sudden= ly > break". I submitted a bug report about --depclean back in the summer o= f > 2021 (though I can't find that bug any more). I think it was closed as= > not-a-bug. >=20 > There are several ways this could have been fixed, for example with > --depclean preserving packages in system, as well as world. But it was= > regarded as not a bug. >=20 > So I think it is fair to say that the Gentoo developers are content for= > some systems (in particular, mine) suddenly to break. I am thus somewh= at > sceptical about things in Gentoo which may be based on assumptions whic= h > don't hold in my system. The new +wayland USE flag kind of looked a bi= t > like that to me. Actually, it wasn't, so I apologise for my opening > post. There is nothing sudden about this! No change has been made! According to your explanation, the presence of daemontools on a system has always made --depclean result in potentially making a system unbootable. The Gentoo developers have taken no action to *make* this a problem. It is the unfortunate combination of a number of moving parts that together result in a historically present issue. Inferring from here that Gentoo developers making an active profile change with the intent of resulting in systems suddenly breaking while dismissing concerns, is unreasonable, irrational, and paranoid. Sorry. Gentoo works better when users report issues and ask for them to be fixed= =2E Gentoo works better when users see a change and ask what the ramifications are, e.g. "I was curious whether this would have a negative effect on my X-only system", rather than immediately leaping to "PSA!!! DANGER ALERT! CODE RED, ALL GENTOO USERS BEWARE!!!" You can always post the "PSA!!! DANGER ALERT! CODE RED" if you asked for information and did not get an answer that satisfied you, but the initial assumption of good faith would be appreciated. =2E... Regarding the daemontools situation: """ for example with --depclean preserving packages in system, as well as wor= ld """ Is not a valid suggestion, since --depclean already does precisely this, but openrc isn't a package in system, it is a package that satisfies a recursive dependency of system. As far as portage knows, it is already doing exactly what you want it to do, as described in the Package Manager Specification. Perhaps you meant to say that --depclean should preserve all versions of an "any-of" dependency. This would break a whole lot of use cases, as then one would no longer be able to change their system to suit themselves using the intended power of virtuals. For example, it would become impossible for a user to install s6-rc into their world file, with the intention of using s6-rc as their service manager, and then --depclean and remove openrc which they no longer intend to use! (It would also be impossible to install vim or emacs, then uninstall nano. For that matter, it would be impossible for an emacs user to install vim, try it out for a day, decide they don't like it, and uninstall vim. Vim would be there to stay: forever.) Normally, installing s6-rc is an intentional action to use s6-rc. But apparently, "normally" installing daemontools isn't an intentional action to use daemontools. Thus, reporting this as a bug against portage is illogical, but reporting it as a bug against virtual/service-manager is logical. I can understand why a bug submitted "about --depclean" would be closed as not-a-bug, since it is... not, in fact, a bug, there is a totally different bug. Perhaps the person who closed that bug should have thought deeper about the implications of such a thing, and reassigned that bug to the correct package with a fixed explanation. And perhaps you should have communicated better why it's a problem for you to install daemontools *without intending to* and having that affect openrc. For example, by highlighting that daemontools isn't being used as a service manager and you do not believe installing "ordinary applications such as qmail" should be allowed to override your choice of init system. --=20 Eli Schwartz --------------8rM0CAVi7aV8XCVYIfUEuTq9-- --------------RDYua8gLMPuyxvJt3iuhmVjH Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZvLXfgUDAAAAAAAKCRCEp9ErcA0vV4L7 AP4qAss4wkqIeHjkxaLea9zYcpc7KRQjuB48xFW+ch6JvwD/VrgLGTSiYTjER5sqCZZtQxyhnCQf wg5Y9sPDpr2NKAE= =BPTU -----END PGP SIGNATURE----- --------------RDYua8gLMPuyxvJt3iuhmVjH--