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 (4096 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 61547158042 for ; Sun, 27 Oct 2024 01:53:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7D073E0887; Sun, 27 Oct 2024 01:53:20 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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 24AA4E087B for ; Sun, 27 Oct 2024 01:53:20 +0000 (UTC) Message-ID: Date: Sat, 26 Oct 2024 21:53:15 -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> <4219bce4-f14f-4c5d-a52a-a303dd583907@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="------------bm0dWOQ44aS0NJCqOEcp8hqc" X-Archives-Salt: bc1121c7-82aa-413e-86af-baf2177f68e8 X-Archives-Hash: cac0816434ec439acd2d363908eea5aa This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bm0dWOQ44aS0NJCqOEcp8hqc Content-Type: multipart/mixed; boundary="------------IPdpzrG80d9DzHzOl0bYXnoL"; protected-headers="v1" From: Eli Schwartz To: gentoo-user@lists.gentoo.org Message-ID: 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> <4219bce4-f14f-4c5d-a52a-a303dd583907@gentoo.org> In-Reply-To: --------------IPdpzrG80d9DzHzOl0bYXnoL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/25/24 3:22 PM, Alan Mackenzie wrote: >> Since it is "just a package", the solution should lie in fixing >> ::gentoo, not in fixing the "emerge" command. That's what the re-opene= d >> bug is about. :) >=20 > What is getting fixed are the data. That leaves the same problem in th= e > emerge code to bite again the next time there are faulty data. I would argue the precise opposite, that the job of emerge is to faithfully do what you tell it to do and the job of ::gentoo is to not tell emerge to do stupid things. We should fix bugs, not break tools by assuming bugs won't be fixed. Especially when no clear proposal about how emerge should be changed exists (ideally in the form of a detailed feature request on the Portage bugtracker). >> Recommending an option that can break your system is a workaround, not= a >> solution. Surely we want to end up in a good state of affairs, eventua= lly? >=20 > We've already established that --depclean can break one's system, not > just theoretically but in real world use. --unmerge is surely safer - > you're unmerging specific packages which, presumably, you've already > checked for safety. "we" have established no such thing. You claim that --depclean can break one's system, I disputed this notion and claim that virtual/service-manager can break one's system. You may argue all you want -- I cannot provide any guarantees about whether other people will agree with you that the problem is portage, but I'm always open to hearing persuasive arguments. On that note I am happy that there was reasonable discussion on the bug report at https://bugs.gentoo.org/803878 but also somewhat disappointed that despite what seems like a lot of support for making the proposed fix, no one has actually stepped up and made that fix yet... > There doesn't appear to be anything better in emerge - I've looked but > not found an emerge action to unmerge specific packages only, apart fro= m > --unmerge. Why is there not a version of --unmerge which does safety > checks first? >=20 > The envisaged work flow seems to be doing things like --deselect, > followed by --depclean, praying that the latter isn't going to break th= e > system. Given how much safer --unmerge is than --depclean, I don't > understand why the emerge man page puts a bold face warning right at th= e > start of --unmerge, but not on --depclean. I find this wording confusing and difficult to understand on your part. There is no option to unmerge specific packages only, using "--unmerge". I just tried it: ``` # emerge --unmerge emerge unmerge can only be used with specific package names ``` Oops? Your claims are totally invalid. I am nitpicking about this for an extremely good reason. Since --unmerge requires you to *specify the package name* (and since you have used it a lot, you surely know this fact) I don't think it should come as a shock t= hat ``` # emerge --depclean CAT/MYPKG ``` also works. And, lo and behold -- it is a version of --unmerge that unmerges specific packages only, which does safety checks first. This is also how I use --depclean by the way. I generally never depclean all packages, I take a look at what "emerge --depclean --pretend" suggests can be depcleaned and then decide whether I want to selectively depclean some of them by name. I will say that I wish --depclean accepted glob patterns which would then match only on packages which are eligible for default-depcleaning. I have a small awk script that processes the output of "emerge -cpq" to select packages that aren't required by @world which match specific patterns such as language-specific categories for libraries, so e.g. I can depclean "all dev-perl stuff unless another package needs it"... >> The emerge manpage warns you against using --unmerge for good reason. >=20 > But doesn't state that reason or give a workable alternative. Saying i= t > can remove important packages is unhelpful if it doesn't give an > alternative which can't. >=20 > My current workflow for clearing out orphaned packages is to do emerge > -p --depclean, then use emerge --unmerge on those packages listed which= > aren't critical system packages or needed application programs. =2E.. again, it literally says to use --depclean, but I'm increasingly getting the feeling that you are not *aware* that --depclean accepts package names. I find this odd, since the manpage entry for --depclean says it pretty clearly: """ Depclean serves as a dependency aware version of --unmerge. When given one or more atoms, it will unmerge matched packages that have no reverse dependencies. """ > --depclean is too clumsy. It assumes I want to unmerge nano, for reaso= ns > which are surely not intended UI, but just because that's the way it wa= s > implemented. I think a --ask flag only asks whether to delete all list= ed > packages or none, not each package individually. What I would prefer i= s > an interface by which _I_ specify which packages are to be removed. Implementing a per-package ask seems like it would be challenging, as it would have to go back and recalculate which packages can still be asked about if you respond "no" to some package that other packages depend on. It does sound like an interesting idea though -- maybe worth submitting a feature request? --=20 Eli Schwartz --------------IPdpzrG80d9DzHzOl0bYXnoL-- --------------bm0dWOQ44aS0NJCqOEcp8hqc Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZx2dDAUDAAAAAAAKCRCEp9ErcA0vVzfn AQDBUW+AP8n6HHUfbhHcX2KzlmjnoqrwkHvektFcu8yfhwD9GKm2BXq68UXELGZEtX1P6s7PqJrq hsYU0xmjuCbOQwQ= =kCDn -----END PGP SIGNATURE----- --------------bm0dWOQ44aS0NJCqOEcp8hqc--