Re: [gentoo-dev] GLEP 19, reloaded (again)

[Marius Mauch]

On 08/10/04  Chris Gianelloni wrote:

> I didn't think anything actually used overlays.  The emerge glsa was
> being designed to work like "emerge system" or "emerge world".  It
> would require a regular "emerge sync" step to work properly... at
> least, that was my understanding.  Forgive me if I'm wrong on that.

Interesting to see people talking about things that aren't completely
implemented yet ;)
At the moment GLSAs reside in $PORTDIR/metadata/glsa and on
http://www.gentoo.org/security/en/glsa, the current code (used by
glsa-check) only looks at the former location. However I've written the
code in a way so that the location can be changed in the same way as
other portage variables (in make.* or on the commandline), so it's not a
problem to change the location in the profile, however you'll have to
find a way to get the GLSAs there. I originally also planned to
implement a way to get the GLSAs directly over http, but that's more
complicated than I thought first (and not very useful for our current
tree anyway).

> Personally, I think there should be as little change for the user as
> possible.  Breaking "emerge sync" is probably not the best way to go
> about it.  Causing "emerge sync" to perform a slightly different
> function, though with the same results (getting new ebuilds) is
> probably the way to go.  While I doubt we would be using gensync
> directly, it definitely gives us a strong starting point.  I am going
> to say that I wouldn't be opposed to using gensync and a separate
> repository, I just think it ends up being overly complex, as if we're
> going to be offering it as an "official" Gentoo release, we should add
> proper support into the tools we already have (portage).  Also, using
> portage and emerge sync for updates allows a user to switch to the
> "current" tree with almost no work.

As for generating a frozen tree I understand that there are basically
two options: a) use our current (changing) tree and only freeze the
versions of packages in the profile or b) create a new tree that 
doesn't change at all (maybe even limited to only include supported
packages/versions). The first is easier to implement but has IMO several
problems:
- we can only limit a package to a specific version, but not "remove" a
complete package that we don't want to support (under the assumption
that we're not going to support the whole tree)
- I doubt that a "packages" file with several hundred (or thousand)
entries is someting most developers want to maintain
- As Spider has already mentioned: It doesn't guarantee a definite base
system as the tree (including the profile) can change over time.

That leaves us with option b): We already offer tarballs of the portage
tree, including the tarballs used to create our releases. People even
have to use them if they want to use GRP. As people already know how to
use them I'd suggest that we use tarballs to provide our frozen tree
(wether we use the existing ones or create special ones is open for
discussion). As this GLEP is looking for a long-term solution we can
probably rely on some portage modifications that will be included in the
version after 2.0.51 that will enhance our `emerge sync` mechanisms
greatly (removing the need for emerge-webrsync and gensync). With these
modifications we can set SYNC to our tarball and offer updates over
rsync/cvs/tarballs/other transport that will be stored in an overlay,
that overlay can then by synced with `emerge --sync updates` ("updates"
is just an example, we can use any name there).
(Anyone interested in the details of the modification see bug 35535).

Marius