On Sun, 9 Jul 2017 21:37:11 -0400 "Walter Dnes" <waltd...@waltdnes.org> 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. > 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. 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. > > 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. -- William L. Thomson Jr.
pgp9xkAQQUKvV.pgp
Description: OpenPGP digital signature
