Re: [gentoo-portage-dev] glsa implemented as a special set

[Ned Ludd]

On Mon, 2006-04-24 at 17:13 +0200, Marius Mauch wrote:
> On Mon, 24 Apr 2006 07:04:13 -0700
> Brian <dol-sen@×××××.net> wrote:
>
> > On Mon, 2006-24-04 at 14:20 +0200, Marius Mauch wrote:
> > > On Sun, 23 Apr 2006 08:55:58 -0700
> > > Brian <dol-sen@×××××.net> 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).

One could use the new postsync hook for doing this via glsa-check 
or a modified copy already.

>
> > >  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

-- 
Ned Ludd <solar@g.o>
Gentoo Linux

-- 
gentoo-portage-dev@g.o mailing list