RE: [gentoo-releng] Gentoo 2004.1 Release

[Daniel Robbins]

> The main objection is not with GRP being used as part of the
> install, but with GRP being used *after* the install, when
> base library versions have been changed, USE flags have been
> modified and so on. GRP as it stands does not work properly
> in these situations.

Yes, exactly. GRP is *only* for a fast install and was never intended to be
used in the way you describe -- for incremental package updates. If users
try to use a GRP set to update their system, we assume they have a clue
about what they're doing. We definitely don't make GRP for that purpose.

I didn't see what the full context of this thread was about. Now that I
have, let me back up and clarify some things.

GRP definition: "Gentoo Reference Platform" -- A set of pre-built packages
created around a defined set of USE flags. Its purpose is to allow for a
rapid install of a very functional Gentoo system. It also establishes a QA
baseline for package building -- since GRP includes popular packages and USE
flags, building a GRP set as part of a release gives us a build and
run-testable set of binaries. GRP is not intended to provide a mechanism to
allow for arbitrary incremental binary package updates over time. This is a
significantly more complex issue.

GLEP 26 "Package Updates": This is different from GRP and should have a
clearly different name. It is intended to keep an installed Gentoo system
up-to-date without any need for compiling packages from source. It requires
significantly more resources.

GRP, as defined above, is essential for Gentoo because fast installs are a
much needed capability.

GLEP 26 "Package Updates" could be useful to people, but also demand a lot
more Gentoo resources and open up a lot more potential problems. GRP
intentionally avoids these issues by defining itself to be an install-only
mechanism.

It's *REALLY* important (red blinking lights) that we do not mix up the
definition of "GRP." A system like GRP is required by the Philosophy of
Gentoo: http://www.gentoo.org/main/en/philosophy.xml . Trustees will be
expected to be gentle caretakers by protecting this philosophy and expanding
Gentoo in the spirit of this philosophy. As such, something like GRP is a
required part of Gentoo because many users find themselves in a position
where they don't have the luxury to take the time to build Gentoo from
sources and we should not be "from source" snobs and expect them to jump
through unnecessary hoops and do things "our way." That's contrary to the
Gentoo philosophy.

But something like GLEP 26 "package updates" is not a required part of
Gentoo. I think it's an admirable goal once someone figures out a way to get
it working predictably and reliably, and users could enjoy this capability.
At the same time, its benefits need to be weighed against the robustness of
the actual implementation (is it worth it? Does it work well enough) and the
amount of developer and infrastructure resources it could eat up (which, if
too ambitious, could be HUGE.)

My main concern is not about GLEP 26 itself, but that the *definition* of
GRP will be expanded to include the stuff being worked on for GLEP 26, and
then GRP will get a bad reputation if it becomes too cumbersome for some
developers to handle. Then  "from source" snobs (for lack of a better term)
might be tempted to push for the elimination of GRP (install-only *and* the
new updates) in their entirety, and users and Gentoo would suffer.

As the ex-releng manager: our quarterly release schedule is already very
ambitious. Yes, catalyst makes quarterly releases easy and I have full
belief that quarterly releases are very good for Gentoo (particularly QA,)
but it does demand quite a bit of mirroring resources and we have yet to see
how these additional demands will play out over a year's time. I don't see
anything wrong with pursuing GLEP 26 other than it has the potential of
being a bit too ambitious and thus draining on the project as a whole.

My recommendation then is to explore the possibility of incremental binary
updates for Gentoo 2005+, after Gentoo gets a good idea of our annual mirror
growth and quarterly releases. Also, releng will then have an established
track record of success (this is also a trust issue I think.) 

I also recommend considering a *distributed* model for the GLEP 26. Here's
what I mean: create the catalyst technology to allow anyone to make their
own GLEP 26 binary package update sets easily. Then these can be built by
non-Gentoo-devs and _hosted_ on non-Gentoo infrastructure. In fact, we can
encourage others to do this. Then our developers can get a bit of relief
from the build process and focus more on developing things. 

Let me just conclude this by saying that it *is* a major issue when users
have to rebuild Mozilla or OpenOffice 3 times a week due to minor rev
updates. It *is* definitely worthwhile to look into a solution to this
problem. However, maybe our first step should be to try to find a way to
limit weekly -rev bumps. Too-frequent -rev bumps hurt everyone, and the new
GLEP 26 solution will only solve this issue for those who choose to use our
pre-built packages. It will not solve the -rev bump issue for those updating
from source (who will very likely be the vast majority of Gentoo users for
the forseeable future.)

Sorry for the long email - I was a bit confused at first and that didn't
help.

Regards,

Daniel


--
gentoo-releng@g.o mailing list