1 |
I had an idea this morning about implementing glsa as a special set. I |
2 |
know the current portage code base is not ready for /etc/portage/sets |
3 |
support, but I thought it might be an easy way to integrate a glsa |
4 |
up/downgrades group (set) listing in portholes upgrades view (needs some |
5 |
familiarity of porthole's gui). |
6 |
|
7 |
I was thinking that /etc/portage/sets/glsa could be a symlink to set |
8 |
list in the current metadata/glsa directory of the portage tree. That |
9 |
file should be relatively easy to auto-generate from the existing |
10 |
glsa*.xml files there already. Perhaps a FEATURES="GLSA_SET" would |
11 |
generate that file on completion of an "emerge --sync" I could also |
12 |
then put a GLSA field into porthole's package Summary view as well as a |
13 |
GLSA notebook page(s) to display the appropriate glsa?.xml file(s). |
14 |
|
15 |
What do you think of the idea? Then as portage/pkgcore gets sets |
16 |
support all anyone would need do is: |
17 |
|
18 |
# emerge -upv glsa |
19 |
(or any proper way emerge will handle set names) |
20 |
|
21 |
for a cli listing of packages needing attention. The one thing I can |
22 |
think of that would need slightly different handling from normal set |
23 |
parsing would be to only list those qualifying packages that are |
24 |
installed and ignore any other not installed package listed. |
25 |
-- |
26 |
Brian <dol-sen@×××××.net> |
27 |
|
28 |
-- |
29 |
gentoo-portage-dev@g.o mailing list |