On Mon, 24 Apr 2006 07:04:13 -0700 Brian <[EMAIL PROTECTED]> wrote: > On Mon, 2006-24-04 at 14:20 +0200, Marius Mauch wrote: > > On Sun, 23 Apr 2006 08:55:58 -0700 > > Brian <[EMAIL PROTECTED]> wrote: > > > > > I was thinking that /etc/portage/sets/glsa could be a symlink to > > > set list in the current metadata/glsa directory of the portage > > > tree. That file should be relatively easy to auto-generate from > > > the existing glsa*.xml files there already. Perhaps a > > > FEATURES="GLSA_SET" would generate that file on completion of an > > > "emerge --sync" I could also then put a GLSA field into > > > porthole's package Summary view as well as a GLSA notebook > > > page(s) to display the appropriate glsa?.xml file(s). > > > > Too complicated. First you currently need gentoolkit for glsa.py, > > and portage shouldn't depend on gentoolkit. > > I did not mean portage should and I din't want to depend on gentoolkit > either.
Not sure I understand your idea then, I was under the impression that
`FEATURE=GLSA_SET emerge --sync` would create that file, is that not
what you meant?
> > Also you can't store
> > system-specific files in the tree.
>
> Yeah, that was a bit of a thought evolution while I was typing. I
> realized after I hit "send". At first I thought it could be included
> in the sync. Then thought it's only a duplication of the data already
> there, so why not generate it (save bandwidth), since the data will
> only change at sync time, just do it once then.
Ehm, you couldn't include it in the sync as it's system specific. It
would have to be generated locally, or you have to treat it special
again (only update packages that are installed, don't install new
packages).
> > And finally using an intermediate
> > file creates some additional issues (check for IO/FS problems,
> > checking permissions, etc).
> > Any reason you need a real file for this instead of just generating
> > the list on the fly?
>
> I thought a smaller stripped down glsa.py module could generate the
> file at completion of the sync. Then no special code is needed
> internal in porthole beyond checking for set inclusion, atom
> matching, just a glsa_flag=True to ignore members that are not
> already installed.
>
> Once portage was able to handle sets, it would almost automatically be
> able to handle a glsa set as well. The only difference is not
> installing a set member that is not already installed.
*Shrug*, generating the list dynamically shouldn't take more than 10 or
20 lines using glsa.py, basically it's
pkg_list = []
glsa_list = [Glsa(x) for x in get_glsa_list(glsadir, glsaconfig)]
for x in glsa_list:
if x.isVulnerable():
pkg_list.extend(x.getMergelist())
plus some error handling. Add some dep_getkey() calls if you don't want
the glsa resolver logic of minimal intrusion (might be problematic
though).
If you need a file interface wrap the list in a StringIO instance.
It's really better to keep interdependencies to a minimum here, and
when portage gets set support it will generate the glsa update list
dynamically anyway, so portage wouldn't benefit from a file at all.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
