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 433BB158083 for ; Tue, 24 Sep 2024 19:36:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 643082BC0BA; Tue, 24 Sep 2024 19:36:47 +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)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 176652BC013 for ; Tue, 24 Sep 2024 19:36:47 +0000 (UTC) Message-ID: Date: Tue, 24 Sep 2024 15:36:43 -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="------------K8G1VN32l0UdBIG8Clyu1tEr" X-Archives-Salt: 0655c223-d801-41e6-a4a2-7073a5b57619 X-Archives-Hash: 1deef32a9653b145b3979a691c077ad0 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------K8G1VN32l0UdBIG8Clyu1tEr Content-Type: multipart/mixed; boundary="------------LM9axYhQsFiRf88j0LJqFkws"; 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: --------------LM9axYhQsFiRf88j0LJqFkws Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9/24/24 2:53 PM, Alan Mackenzie wrote: >> Regarding the daemontools situation: >=20 >> """ >> for example with --depclean preserving packages in system, as well as = world >> """ >=20 >> Is not a valid suggestion, since --depclean already does precisely thi= s, >> but openrc isn't a package in system, it is a package that satisfies a= >> recursive dependency of system. >=20 > I think that's a rather obscure distinction. Do users actually perceiv= e > virtual packages this way? I certainly don't. >=20 >> As far as portage knows, it is already doing exactly what you want it >> to do, as described in the Package Manager Specification. >=20 > My machine would have become unbootable long before I got around to > reading that spec. Indeed, you are correct, but I am not sure why you'd need to read the spec anyway. That is why I am correct too -- since I am pointing out that things like requesting specific portage / PMS behavior when interacting with virtual packages is not how one should perceive the end-user problem. (A virtual package is "just" a package with no installed files. How virtual packages are used is a matter of Gentoo policy, not a matter of how portage works. And PMS only mentions virtual packages once, and that one time is to state that the old way was removed from the spec and that new style virtuals are "just packages, and have no special treatment".) Since it is "just a package", the solution should lie in fixing ::gentoo, not in fixing the "emerge" command. That's what the re-opened bug is about. :) >> 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. >=20 > What is wrong with # emerge --unmerge? I fail to see why that isn't > entirely satisfactory. 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, eventually= ? The emerge manpage warns you against using --unmerge for good reason. >> (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.) >=20 > What about the users, who can't be all that rare, who wish all of nano,= > vim, and emacs to be installed? They're application programs, not syst= em > services. If you want all 3, then virtual/editor isn't an appropriate way to install a large collection of apps. Add them to your world file. virtual/editor doesn't restrict how many editors you have installed, it simply requires you have at least one. And it shouldn't require that any editors you install, cannot be uninstalled with --depclean --=20 Eli Schwartz --------------LM9axYhQsFiRf88j0LJqFkws-- --------------K8G1VN32l0UdBIG8Clyu1tEr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZvMUywUDAAAAAAAKCRCEp9ErcA0vV1ch AP9LIVz8EXUEmgXFBtRa+Vj7TZmeqcJyff/hdVTQetP8RQEAmIxw2iIXIXuasbuqp+Oji6zxHp7j ziIl9fLqmfYYFg4= =WKfQ -----END PGP SIGNATURE----- --------------K8G1VN32l0UdBIG8Clyu1tEr--