On Wed, 2004-08-11 at 00:22, Marius Mauch wrote:
> 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).

So I was half right... Thanks for filling in the gaps.

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

I think the release tarballs are a good start.  I'm more than willing to
work to make the tarballs to provide what is wanted for the GLEP.

I definitely think that what we use for releases should match the frozen
tree that coincides with that release.  It means there would be only one
set of packages to support, which makes things very easy, and as I said,
even allows for possible binary updates in the future, if we so desired.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?