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

[Brian]

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.

>  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-sen@×××××.net>

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