1 |
On 06/16/2012 02:56 PM, Duncan wrote: |
2 |
> Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets. |
3 |
> Since I've been working with kde4 since it was overlay-only and sets- |
4 |
> only, no meta-packages, I've been using sets for quite awhile and it's |
5 |
> now entirely integrated into how I work with portage. |
6 |
> |
7 |
> When I setup my netbook on gentoo, I wanted most of the same setup as on |
8 |
> my main machine, but with some differences, so I had to go thru the main |
9 |
> machine's world file and pick and choose what I needed. |
10 |
> |
11 |
> What I quickly realized is that my kde packages were already nicely |
12 |
> categorized into sets, so all I really needed to do was split up the rest |
13 |
> of the world file into a bunch of other sets, by category. So for |
14 |
> instance: |
15 |
> |
16 |
> $>>cat /etc/portage/sets/jed.dev |
17 |
> dev-util/ccache |
18 |
> dev-util/desktop-file-utils |
19 |
> dev-vcs/git |
20 |
> sys-devel/bin86 |
21 |
> sys-devel/gcc |
22 |
> sys-devel/gdb |
23 |
> |
24 |
> |
25 |
> I have 24 such sets including my (customized) kde sets. All packages |
26 |
> formerly listed in the world file are found in these sets, instead, and |
27 |
> of course the sets are in turn listed in /var/lib/portage/world_sets. |
28 |
> |
29 |
> My world file is normally entirely empty, tho I do use it occasionally |
30 |
> for packages I haven't decided whether I want to keep or not, but want to |
31 |
> protect from --depclean, which I run after each update. So my world file |
32 |
> serves as a kind of package purgatory, until I decide whether it's going |
33 |
> to be a part of my normal system, or removed. |
34 |
> |
35 |
> The sets, meanwhile, break the former world file down into much more |
36 |
> manageable categorized chunks, each of which is short enough and |
37 |
> categorized specifically enough that if a package is no longer needed, it |
38 |
> immediately sticks out like a sore thumb, as it's not lost among the |
39 |
> noise of hundreds of "twisty packages, all different". =:^) |
40 |
> |
41 |
> |
42 |
> While not a direct solution to the problem at hand, proper use of sets |
43 |
> WILL and DOES dramatically ease gentoo world-package administration, |
44 |
> going a long way toward eliminating crufty world lists simply by allowing |
45 |
> them to be cut into nice little chunks that can be categorized in ways |
46 |
> that make sense for an individual site, so the cruft sticks out like the |
47 |
> sore thumb it can really be, and is thus easily found and removed. |
48 |
> |
49 |
> |
50 |
> Meanwhile, another bonus of sets is the extra protection it gives you if |
51 |
> you try to emerge -C something in a sets file (as opposed to the world |
52 |
> file itself). =:^) Seeing that warning that the package is in a set and |
53 |
> can't be directly unmerged is rather like seeing the warning that it's in |
54 |
> @system, except that user sets are easier to directly manage, and it has |
55 |
> saved my butt a couple times when I was really too sleepy to be adminning |
56 |
> the system in the first place. But it's easy enough to remove (or |
57 |
> comment) that line from the set, if removal is really intended, and |
58 |
> that's what would ultimately need to be done anyway, to prevent it |
59 |
> getting remerged. |
60 |
> |
61 |
> |
62 |
> Unfortunately, it has begun to look like sets are where baselayout2 and |
63 |
> openrc were for many years, "forever coming, never getting here", at |
64 |
> least for stable or even unmasked into ~arch. =:^( |
65 |
|
66 |
Support for /etc/portage/sets is included in portage-2.1.11: |
67 |
|
68 |
https://bugs.gentoo.org/show_bug.cgi?id=384061 |
69 |
-- |
70 |
Thanks, |
71 |
Zac |