Re: [gentoo-dev] Revisiting GLEP 19

[Michael Marineau]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Crete wrote:

| On Wed, 2004-07-21 at 16:00 -0400, Chris Gianelloni wrote:

|>I can see how profiles could be used to accomplish this sort of thing,
|>but pinning of versions would not be the way to go about it.
|
|
| I agree

I second that, profiles seem like something that is far to static to work well
with security updates and allowing site admins to upgrade specific packages if
they choose to do so.
|
|
|
|>For simplicity, I'm going to name everything, but none of this is set in
|>stone.  For one, the "gentoo-x86" CVS module would be come
|>"gentoo-current", as it reflects the actual usage and state of the
|>tree.  The profiles in the current tree would have their versions
|>removed, as this is a fluid target.  This matches our current tree the
|>best, and allows for us to make dynamic changes to the profiles between
|>releases.  For example, default-x86-2005.0 (or
|>default-linux/x86/2005.0), would become default-linux/x86/current.  Each
|>release tree would be identified as such.  I'm going to work with
|>cascading profiles, to make my life easier.  At release time, a branch
|>is made for the release.  We would take the stable ebuilds/packages from
|>gentoo-current and drop it into gentoo-2005.0-release and a new profile
|>default-linux/x86/2005.0 would be created.  This profile would never
|>change.  If there were multiple sets of stages created, such as the
|>amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4
|>stages, a sub-profile would be created,
|>default-linux/amd64/2005.0/gcc34.
|>
|>At this point, the -release tree is turned over to -releng and the arch
|>leads/maintainers for preparation for the impending release.  If changes
|>are needed that only affect the LiveCD/GRP, they go into the tree
|>directly.  If changes are needed that affect the package as a whole, the
|>package maintainer is contacted, and the package is fixed in both the
|>-current and -release trees.  At some point, the tree is frozen and a
|>snapshot is made.  This becomes the official snapshot for that release.
|>A new rsync mirror set is created for the tree, and the make.globals
|>SYNC is set to that new rsync mirror,
|>rsync://rsync.gentoo.org/gentoo-2005.0-release/.  The stages/LiveCD/GRP
|>is built for the release, and everything is golden.  The things that are
|>marked as "stable" are never changed via rsync in this tree, as they are
|>the unchanging base.  The release is made, the planets align, and there
|>is peace for a thousand generations...
|
|
| I like the idea of a separate tree.. But if it really rarely changes,
| rsync is just overkill and will overburden our mirrors.. Lets just make
| it a tarball and put the enhancements in a rsync'ed overlay. Rsync is
| for stuff that changes...

I also like the seperate trees.  And splitting out the base system into a
tarball and putting only updates in the rsync tree is certainly doable.
However, dividing out between a release tarball and synced updates begins to
distroy the elegence that only switching a portage tree has.  I don't really
see why using rsync will overburden the mirrors any more than they are now.
Afterall, currently everyone has to rsync.  If it is so important to use
tarballs maybe it would work to just provide update snapshots that can be
downloaded and inserted into the existing tree. Snapshots could be done by
either grabbing the whole tree or just include new or updated ebuilds.  Basicly
it would be encouraging enerprise users to use emerge-webrsync instead of
emerge sync.  Personally though, I don't think avoiding rsync would really help
that much.
|
|
|
|>...until disaster strikes and a package has a security vulnerability.
|>At this point, the package is patched, a GLSA is released, and the new
|>ebuild goes into the tree as ~arch.  You will notice that I have left
|>out the whole "who does the updates" part of this and there is a good
|>reason for it.  I haven't got a clue.  This would need to be decided by
|>interest.  After all, many people are not going to be very excited about
|>applying patches to old versions of software, and that's ok.
|>*** This is the weakness in not only my plan, but ANY "Enterprise
|>Gentoo" plan ***

Who maintains the old trees is a pretty big issue.  Is this more serious than
just determining how many releases to support and will actually limit how
'enterprise' like enterprise gentoo will be?  There have been a far range of
needs that could be addressed.  Can gentoo do it all or just rehash fancy ways
of doing `glsa-check`?
|
|
| This overlays should probably each have their own cvs module (or all be
| directories under the same module, I dont really care... Where all
| package maintainers would have access.. And then we can mark them stable
| using the same kind of procedures we currently use for GLSAs...
|
| Also, the problem with maintaining older versions is that we need to
| have at least one machine available for each version where the concerned
| devs can test security updates.. Ok, maybe at least one per
| architectures using chroots... but its still a lot of  infrastructure..
| That's why reducing the number of stable releases to maybe even just one
| a year might be a good idea.
|
|
|


- --
Michael Marineau
marineam@×××××××××.edu
Oregon State University
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/uawiP+LossGzjARAmYbAJ4sswV9auaRqQAm+sADGL4lTXK90ACeMPIU
3aZUzSmnBx5XAQBfbwh5OBY=
=YC3k
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list