On Sun, 9 Jul 2017 05:24:19 -0400 "Walter Dnes" <waltd...@waltdnes.org> wrote:
> On Sat, Jul 08, 2017 at 09:32:09PM -0400, William L. Thomson Jr. wrote > > On Sat, 8 Jul 2017 20:27:38 -0400 > > "Walter Dnes" <waltd...@waltdnes.org> wrote: > > > > > > > Though I will have to see what happens if a package is listed in > > > > more than one set. I think there is a hierarchy there. > > > > > > I tried "emerge -pv --unmerge @palemoon_build", and it was > > > ready to delete all the stuff, including gcc, etc. > > > > Did you get any warnings? Your about to remove a system package, > > etc. > > Yes, for gcc. Which if someone ignores warnings, and breaks their system, it is on them. At that point your best to remove said package from the set, and then proceed with removing the set. > If / when I unmerge the meta-set, I want to only unmerge stuff that > is not part of (packages I normally require). I do not want all > members of the set unmerged unconditionally, regardless of being > dependancies for packages I still have. That is a matter of knowing what is in the set and on your system. In that case the idea for a set would be to add packages that are NOT part of your normal system. Adding packages part of your system would defeat the benefit. > This is where a meta-package is superior to a set. I simply unmerge > the meta-package, and "emerge --ask --depclean". If a meta-set item > is a dependancy of a package that I'll be keeping, it won't get > removed. I do not want to risk removing a package that is needed > elsewhere. And 2 or 3 years later, I may have installed packages > that have members of the meta-set as a dependancy. A meta-package > removes the risk of shooting myself in the foot. Yes in the case you just add stuff into a set, not paying attention if it is a dep of another package, present or future. Then a meta ebuild does allow someone to be "lazier" ( not insulting you ) and know less about their system and packages. Just toss package names into a ebuild, and not worry if its a dep or not, past, present, or future. 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. > > > I deleted /etc/portage/sets/palemoon_build, and the entry > > > "@palemoon_build" from /var/lib/portage/world_sets. It turns out > > > that all these packages are required anyways. > > > > Meaning little was removed after you did emerge --depclean world ? > > Nothing would've been removed. Several months ago, the hicolor-icon > theme would've been removed. But it has recently been added to the > ever-growing list of gtk dependancies. GTK == GNOME Tool Kit, > regardless of what they officially call it. More a result of RedHat's involvement in both GTK and Gnome. Also FYI High Color should be a dep of all desktops, or anything that complies with freedesktop.org standards. https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout Its where random application icons are installed that are not bound to any one theme. /usr/share/icons/hicolor/ If no theme provides an icon, it looks in hicolor and uses that. > I only ran a "pretend" unmerge, to see what would happen if I did > unmerge the set. As a precaution, I've decided to migrate over to a > meta-package. As per Rich Freeman's recommendation, I'll go with > RDEPEND, and fill in optional descriptive fields in the meta-set. In your case a meta ebuild is likely a better suited for your needs and uses. Yes you want RDEPEND, I was going to comment on that but Rich had already so no need to duplicate. Though technically a meta ebuilds does not need those to run, just the way to pull them in. -- William L. Thomson Jr.
pgpHw5jp3Ev2c.pgp
Description: OpenPGP digital signature
