glsa implemented as a special set

I had an idea this morning about implementing glsa as a
special set.  I
know the current portage code base is not ready for
/etc/portage/sets
support, but I thought it might be an easy way to integrate
a glsa
up/downgrades group (set) listing in portholes upgrades view
(needs some
familiarity of porthole's gui).

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

What do you think of the idea?   Then as portage/pkgcore
gets sets
support all anyone would need do is:

# emerge -upv glsa
(or any proper way emerge will handle set names)

for a cli listing of packages needing attention.  The one
thing I can
think of that would need slightly different handling from
normal set
parsing would be to only list those qualifying packages that
are
installed and ignore any other not installed package listed.
-- 
Brian <dol-sentelus.net>

-- 
gentoo-portage-devgentoo.org mailing list

On Sun, 23 Apr 2006 08:55:58 -0700
Brian <dol-sentelus.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. Also you can't
store
system-specific files in the tree. 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? Just check glsa-check how to do that, it's
not much
more than a wrapper for glsa.py.

Marius

-- 
Public Key at http://www.geno
ne.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.

On Mon, 2006-24-04 at 14:20 +0200, Marius Mauch wrote:
> On Sun, 23 Apr 2006 08:55:58 -0700
> Brian <dol-sentelus.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.

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


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

>  Just check glsa-check how to do that, it's not much
> more than a wrapper for glsa.py.
> 
I have started looking at your work.  Nice by the way , will
probably
use it for an example of how to eliminate the pyxml dep you
consider
evil .
I realize that this method is not as complete and versatile
as what
glsa-check is, but will do what probably the majority of
users
want/require/use.

> Marius
> 
-- 
Brian <dol-sentelus.net>

-- 
gentoo-portage-devgentoo.org mailing list

On Mon, 24 Apr 2006 07:04:13 -0700
Brian <dol-sentelus.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-sentelus.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).

> >  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.geno
ne.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.

On Mon, 2006-04-24 at 17:13 +0200, Marius Mauch wrote:
> On Mon, 24 Apr 2006 07:04:13 -0700
> Brian <dol-sentelus.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-sentelus.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 <solargentoo.org>
Gentoo Linux

-- 
gentoo-portage-devgentoo.org mailing list