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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A9C5C139694 for ; Mon, 10 Jul 2017 04:43:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3F9EB2741AB; Mon, 10 Jul 2017 04:43:19 +0000 (UTC) Received: from mail2.obsidian-studios.com (mail2.obsidian-studios.com [45.79.71.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CE573274196 for ; Mon, 10 Jul 2017 04:43:18 +0000 (UTC) Received: (qmail 11401 invoked from network); 10 Jul 2017 04:43:17 -0000 Received: from unknown (HELO assp2.obsidian-studios.com) (wlt-ml@::ffff:127.0.0.1) by ::ffff:127.0.0.1 with ESMTPA; 10 Jul 2017 04:43:17 -0000 X-Assp-Version: 2.5.5(17073) on assp2.obsidian-studios.com X-Assp-ID: assp2.obsidian-studios.com m1-61796-11102 X-Assp-Session: 2736AC1438 (mail 1) X-Assp-Envelope-From: wlt-ml@o-sinc.com X-Assp-Intended-For: gentoo-dev@lists.gentoo.org X-Assp-Server-TLS: yes Received: from unknown ([fdbe:bad:a55:0:1::211] helo=localhost) by assp2.obsidian-studios.com with SMTPSA(TLSv1_2 ECDHE-RSA-AES128-GCM-SHA256) (2.5.5); 9 Jul 2017 21:43:16 -0700 Date: Mon, 10 Jul 2017 00:43:11 -0400 From: "William L. Thomson Jr." To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Sets vs Meta ebuilds Message-ID: In-Reply-To: <20170710013711.GA8455@waltdnes.org> References: <7513ca72-4ca2-ae77-3321-cdb12263af2f@gentoo.org> <20170709002738.GA28879@waltdnes.org> <20170709092419.GA5124@waltdnes.org> <20170710013711.GA8455@waltdnes.org> Organization: Obsidian-Studios, Inc. X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/EpYdhV1QUbBsPWNM8wSNNLM"; protocol="application/pgp-signature" X-Archives-Salt: d2d80e7b-782f-461b-b6d5-6d6984855c80 X-Archives-Hash: dedac1b9665fbcf6d63a2cbf8a7e0e47 --Sig_/EpYdhV1QUbBsPWNM8wSNNLM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 9 Jul 2017 21:37:11 -0400 "Walter Dnes" wrote: > > "Fat-Finger" does happen once in while. Removing the risk of it > happening in the first place is a lot more robust/bulletproof. There is nothing in place to stop you from removing gcc, or other system packages. Adding such to a set, removing them, then expecting the system to prevent you from doing that. Really does not make sense. You are creating the set. You are also ignoring warnings on un-emerge. That is several mistakes. Either way, removing gcc as part of a set, or directly, or any other system package can happen regardless. There is nothing bullet proof. Nothing to stop you either way, except the warning. =20 > Everybody who doesn't run LFS (Linux From Scratch) is "lazy" in that > regard. Figuring out dependancies is the job of a package manager, > not the end-user. Dependencies are really not part of the sets discussion. That came from something you had mentioned about deps remaining after removing a set. > I may be getting old, and my head may be slowly > becoming like that of Captain Picard in STTNG (Star Trek The Next > Generation). I do appreciate being able to decide I want something > installed and telling Portage to "Make it so", and letting it take > care of details. Then do so, but if you start creating sets, and doing bad stuff in that process. Really cannot blame sets. > a) I don't want to have to spend time figuring out if an item is or is > not a deep dependancy of a package I currently have. Packages added to a set are rarely deps of each other, and usually unrelated packages. It depends on the set, and in this case we are talking user created set. Which means you are only adding packages you want to the set. From there portage handles deps like normal. I fail to see the issue. > b) I may install other packages later on which may have items already > in the set as a dependancy. Then maybe you should avoid using sets. If your not going to pay attention to what you put in them. Just to remove. But again if its a dep of another. Assuming your doing things properly and doing a world update after any package removal. Any deps removed would be brought back in. But your missing that you are creating all this yourself. You do not have to create a set. If you do and remove it. Then you should be familiar with the package you are putting in the set, and if it is a dep of other stuff. Its bad administration to just toss something into a set. For that package to become a dep of something else on the system. The package being in the set serves no purpose then. > c) Even if *I* don't change "world", GNOME's ever-growing hard-coded > dependancy list will change.=20 Then seems like you will need to constantly review the packages you put into a set and remove any that are brought in by other things. It seems like for what you are doing sets are not good. For others they maybe, who are doing things differently. > > It is a way to go, but others may want more fine grained control and > > have more awareness of package dependencies, and only add non > > dependent non-system packages to a set. =20 >=20 > Assuming it's not a lot of additional work, what exactly do sets > allow that meta packages don't? If you followed the thread. It allows you to directly remove the packages without having to depclean or remove the packages individually as a list. Also you can rebuild said packages. The rebuilding on demand is likely the biggest feature. You cannot rebuild a meta package on demand. You can rebuild the meta package, but not the packages in the meta package. You would have to list those one by one. Thus using a set is much easier. --=20 William L. Thomson Jr. --Sig_/EpYdhV1QUbBsPWNM8wSNNLM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTEeldqZjmVut8bVHJNcbKkg6ozUAUCWWMF3wAKCRBNcbKkg6oz UMPiAKCEZkEOnRKcbbmHDolkIU4avqbu9wCgjgTQ7GMN0s0YK/BhlYf5m2qvs38= =NF8n -----END PGP SIGNATURE----- --Sig_/EpYdhV1QUbBsPWNM8wSNNLM--