[gentoo-releng] Gentoo 2004.1 Release

[gentoo-releng] Gentoo 2004.1 Release

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi all -
I am pleased to announce the release of Gentoo 2004.1. Please hit up
your favorite mirror and let the good times flow :) (Link to press
release on the g.o mainpage)

Special thanks to the members of releng, infra, and the developer
community at large for making 2004.1 the smoothest and highest-quality
Gentoo release to date. 2004.1 set a new release paradigm for Gentoo and
we fully expect to continue it far into the future. Expect more and you
shall receive :)

With all of that said, I am taking a couple of days off to relax - I
recommend the rest of releng do the same :)

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Nathaniel McCallum]

I thought online GRP packages would be with this release, however, I'm
not seeing GRP packages on any of the mirrors.  Am I in
cloud-cuckoo-land?

Nathaniel
On Tue, 2004-04-27 at 23:52 -0400, John Davis wrote:
> Hi all -
> I am pleased to announce the release of Gentoo 2004.1. Please hit up
> your favorite mirror and let the good times flow :) (Link to press
> release on the g.o mainpage)
> 
> Special thanks to the members of releng, infra, and the developer
> community at large for making 2004.1 the smoothest and highest-quality
> Gentoo release to date. 2004.1 set a new release paradigm for Gentoo and
> we fully expect to continue it far into the future. Expect more and you
> shall receive :)
> 
> With all of that said, I am taking a couple of days off to relax - I
> recommend the rest of releng do the same :)


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

On Wed, Apr 28, 2004 at 05:36:13PM -0400 or thereabouts, Nathaniel McCallum wrote:
> I thought online GRP packages would be with this release, however, I'm
> not seeing GRP packages on any of the mirrors.  Am I in
> cloud-cuckoo-land?

This didn't make it into 2004.1.  

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Wed, 2004-04-28 at 17:52, Kurt Lieber wrote:
> On Wed, Apr 28, 2004 at 05:36:13PM -0400 or thereabouts, Nathaniel McCallum wrote:
> > I thought online GRP packages would be with this release, however, I'm
> > not seeing GRP packages on any of the mirrors.  Am I in
> > cloud-cuckoo-land?
> 
> This didn't make it into 2004.1.  
> 
> --kurt

I purposely excluded them because I am working on the following:
http://dev.gentoo.org/~zhen/glep0026.txt

Keep in mind that it is very, very rough. Very. I mean it! You get the
jist though. Now that 2004.1 is done, I can focus some of my time on it
and make it formal.

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

On Wed, 2004-04-28 at 17:58, John Davis wrote:
> On Wed, 2004-04-28 at 17:52, Kurt Lieber wrote:
> > On Wed, Apr 28, 2004 at 05:36:13PM -0400 or thereabouts, Nathaniel McCallum wrote:
> > > I thought online GRP packages would be with this release, however, I'm
> > > not seeing GRP packages on any of the mirrors.  Am I in
> > > cloud-cuckoo-land?
> > 
> > This didn't make it into 2004.1.  
> > 
> > --kurt
> 
> I purposely excluded them because I am working on the following:
> http://dev.gentoo.org/~zhen/glep0026.txt
> 
> Keep in mind that it is very, very rough. Very. I mean it! You get the
> jist though. Now that 2004.1 is done, I can focus some of my time on it
> and make it formal.

Note that this may make compile time on other-arch boxes a bottleneck,
especially if every change is expected to be provided in GRP form. I
would more strongly support a consistent release cycle for GRPs
(bi-quarterly, perhaps) with exceptions for security or
otherwise-critical updates.
-- 
Donnie Berkholz
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Pieter Van den Abeele]

Maybe a dumb question, but wouldn't it be possible to just provide GRP 
instead of the stage2,3 (= one huge GRP tarball anyway).

Pieter

On 29 Apr 2004, at 01:00, Donnie Berkholz wrote:

> On Wed, 2004-04-28 at 17:58, John Davis wrote:
>> On Wed, 2004-04-28 at 17:52, Kurt Lieber wrote:
>>> On Wed, Apr 28, 2004 at 05:36:13PM -0400 or thereabouts, Nathaniel 
>>> McCallum wrote:
>>>> I thought online GRP packages would be with this release, however, 
>>>> I'm
>>>> not seeing GRP packages on any of the mirrors.  Am I in
>>>> cloud-cuckoo-land?
>>>
>>> This didn't make it into 2004.1.
>>>
>>> --kurt
>>
>> I purposely excluded them because I am working on the following:
>> http://dev.gentoo.org/~zhen/glep0026.txt
>>
>> Keep in mind that it is very, very rough. Very. I mean it! You get the
>> jist though. Now that 2004.1 is done, I can focus some of my time on 
>> it
>> and make it formal.
>
> Note that this may make compile time on other-arch boxes a bottleneck,
> especially if every change is expected to be provided in GRP form. I
> would more strongly support a consistent release cycle for GRPs
> (bi-quarterly, perhaps) with exceptions for security or
> otherwise-critical updates.
> -- 
> Donnie Berkholz
> Gentoo Linux


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Thu, Apr 29, 2004 at 01:26:13AM +0200, Pieter Van den Abeele wrote:
> Maybe a dumb question, but wouldn't it be possible to just provide GRP 
> instead of the stage2,3 (= one huge GRP tarball anyway).

This isn't as dumb as it sounds. Afaik, people use mainly stage1 and stage3
and the stage1'ers want to have full control and try exploiting as many
tweaks as possible (except for those using stage1 because it's elite) while
the stage3 users hardly change their USE flags anyway.

It's been a while that I've heard from stage2 users. 

Perhaps someone is willing to make a testdrive and create a LiveCD with a
stage1 and the necessary binary packages to make the entire installation
possible without a single compilation (including prebuilt kernels as
mentioned earlier in the thread)?

I'm all in favor of such testdrives, you never know what comes out and the
feedback is enormous.

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Pieter Van den Abeele]

Hi,

A good idea and I don't see any limitations to produce the binaries. 
The only problem I see is dev-side bandwidth (esp. upload) and maybe 
some complications to keep the mirrors up to date (updating the 2004.0 
ppc cds with the bugfixed ones wasn't possible?).

Pieter


On 28 Apr 2004, at 23:58, John Davis wrote:

> On Wed, 2004-04-28 at 17:52, Kurt Lieber wrote:
>> On Wed, Apr 28, 2004 at 05:36:13PM -0400 or thereabouts, Nathaniel 
>> McCallum wrote:
>>> I thought online GRP packages would be with this release, however, 
>>> I'm
>>> not seeing GRP packages on any of the mirrors.  Am I in
>>> cloud-cuckoo-land?
>>
>> This didn't make it into 2004.1.
>>
>> --kurt
>
> I purposely excluded them because I am working on the following:
> http://dev.gentoo.org/~zhen/glep0026.txt
>
> Keep in mind that it is very, very rough. Very. I mean it! You get the
> jist though. Now that 2004.1 is done, I can focus some of my time on it
> and make it formal.
>
> Cheers,
> //zhen
> -- 
> John Davis
> Gentoo Linux Developer
> <http://dev.gentoo.org/~zhen>
>
> ----
> GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
> Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47
>


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

On Wed, 28 Apr 2004 17:58:17 -0400 John Davis <zhen@gentoo.org> wrote:
| I purposely excluded them because I am working on the following:
| http://dev.gentoo.org/~zhen/glep0026.txt
| 
| Keep in mind that it is very, very rough. Very. I mean it! You get the
| jist though. Now that 2004.1 is done, I can focus some of my time on
| it and make it formal.

I suggest you remove anything that doesn't support multiple CPUs
and distcc during build from the list. Otherwise it would take too long
for certain non-x86 archs to build things.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Wed, Apr 28, 2004 at 05:58:17PM -0400 or thereabouts, John Davis wrote:
> I purposely excluded them because I am working on the following:
> http://dev.gentoo.org/~zhen/glep0026.txt
> 
> Keep in mind that it is very, very rough. Very. I mean it! You get the
> jist though. Now that 2004.1 is done, I can focus some of my time on it
> and make it formal.

There are a number of managers and developers who are concerned with the
viability/purpose and value of GRP.  At some point, we will need to
re-visit this and decide if it's in the best interests of Gentoo to
continue supporting, let alone expanding.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On Wed, 2004-04-28 at 19:33, Kurt Lieber wrote:
> On Wed, Apr 28, 2004 at 05:58:17PM -0400 or thereabouts, John Davis wrote:
> > I purposely excluded them because I am working on the following:
> > http://dev.gentoo.org/~zhen/glep0026.txt
> > 
> > Keep in mind that it is very, very rough. Very. I mean it! You get the
> > jist though. Now that 2004.1 is done, I can focus some of my time on it
> > and make it formal.
> 
> There are a number of managers and developers who are concerned with the
> viability/purpose and value of GRP.  At some point, we will need to
> re-visit this and decide if it's in the best interests of Gentoo to
> continue supporting, let alone expanding.
> 
> --kurt

Hopefully this glep will spurn some good conversation regarding GRP.
Personally, I think that it is essential for easy installation, but I
would like to entertain some other opinions.

After I publish this glep, I am hoping that the "some time" to revisit
will be then.

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Wed, Apr 28, 2004 at 07:38:52PM -0400, John Davis wrote:
> Hopefully this glep will spurn some good conversation regarding GRP.
> Personally, I think that it is essential for easy installation, but I
> would like to entertain some other opinions.
> 
> After I publish this glep, I am hoping that the "some time" to revisit
> will be then.

Is the glep removed from your devspace? I can't seem to find it anymore and
it's not published on http://glep.gentoo.org (yet).

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

On Thu, 2004-04-29 at 15:17, Sven Vermeulen wrote:
> On Wed, Apr 28, 2004 at 07:38:52PM -0400, John Davis wrote:
> > Hopefully this glep will spurn some good conversation regarding GRP.
> > Personally, I think that it is essential for easy installation, but I
> > would like to entertain some other opinions.
> > 
> > After I publish this glep, I am hoping that the "some time" to revisit
> > will be then.
> 
> Is the glep removed from your devspace? I can't seem to find it anymore and
> it's not published on http://glep.gentoo.org (yet).
> 
> Wkr,
>       Sven Vermeulen

Yes, I removed it, because it was causing more harm than good at this
point.

GLEP 26 wasn't suppossed to be taken seriously ... yet. It is a massive
work in progress that I have not been able to work on because of 2004.1.
I simply pointed it out to some people as an example. I keep saying it
is an example, and not meant to be implemented anytime in the near
future.

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-releng] Gentoo 2004.1 Release

[Daniel Robbins]

> There are a number of managers and developers who are 
> concerned with the viability/purpose and value of GRP.  At 
> some point, we will need to re-visit this and decide if it's 
> in the best interests of Gentoo to continue supporting, let 
> alone expanding.

Urg, comments like this make me regret that I resigned from the project,
because just killing off GRP would be pretty harmful to the Gentoo user
base. But I guess that one of the risks of setting up a NFP is that the
trustees can shoot themselves in their collective feet if they want. Maybe I
should be glad my feet aren't included :)

If some developers and managers don't see any purpose in GRP, make sure they
have an answer for the thousands of users that they are supposed to be
serving and who depend on it for a fast install.

Eliminating GRP entirely without some larger vision for fast, pain-free
installs is a pretty bad idea. This is particularly important for end-users
who don't have 10 boxes at work to build things on. I would frankly ignore
anyone who doesn't like GRP and has no good proposed alternative for the
many users who use our GRP sets.

If they don't like GRP and have a _better_ idea for fast installs, that's
another thing entirely. Then they are trying to find a better way to address
user needs, rather than just selfishly ignoring them. You need to
differentiate between the two groups to figure out which ones are being lazy
and irresponsible and which are truly concerned for improving Gentoo's
offerings of quality install choices.  So when you mention "there are a
number of managers and developers" that are anti-GRP, it's not as important
*what* they think but *why* they think it.

Regards,

Daniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Wed, 28 Apr 2004 18:22:35 -0600 "Daniel Robbins"
<drobbins@gentoo.org> wrote:
| If some developers and managers don't see any purpose in GRP, make
| sure they have an answer for the thousands of users that they are
| supposed to be serving and who depend on it for a fast install.

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.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

On Wed, 2004-04-28 at 20:58, Ciaran McCreesh wrote:
> On Wed, 28 Apr 2004 18:22:35 -0600 "Daniel Robbins"
> <drobbins@gentoo.org> wrote:
> | If some developers and managers don't see any purpose in GRP, make
> | sure they have an answer for the thousands of users that they are
> | supposed to be serving and who depend on it for a fast install.
> 
> 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.

True enough, I think (hope) that was what Kurt was referring to. The
users *need* GRP for quick installs.

About the non-install GRP. Many users do not care what USE flags they
use or what cflags they compiled with. They install Gentoo, use it, and
that is the end of the story (some users go on to using Gentoo for more
advanced means, but not all users do).

Having GRP that is built with the defaults presented in the system
profile for critical packages is something that we should strive for. If
we make it very explicit that we *will* not offer support for cases when
this GRP was used on a non-default (default meaning they have not
modfied the profile use settings, cflags, etc), then I do not see the
problem. We have to keep in mind that users are NOT developers - they
don't do to their systems what we do to ours. To most users, vanilla
gentoo is just fine. If they decide that it is not, they discontinue use
of the GRP and simply emerge everything from source.

What we offer the users is a win-win situation, they have binary
versions of critical packages for both ease of use and backup purposes
(them: I fried my GCC!!!! Us: ok, grab the package from x mirror to fix
it real quick). Of course, I will put this before -dev and -core, but
please keep an open mind.

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Gustavo Zacarias]

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

John Davis wrote:

| Having GRP that is built with the defaults presented in the system
| profile for critical packages is something that we should strive for. If
| we make it very explicit that we *will* not offer support for cases when
| this GRP was used on a non-default (default meaning they have not
| modfied the profile use settings, cflags, etc), then I do not see the
| problem. We have to keep in mind that users are NOT developers - they
| don't do to their systems what we do to ours. To most users, vanilla
| gentoo is just fine. If they decide that it is not, they discontinue use
| of the GRP and simply emerge everything from source.

By this time i may have had more than enough drinks, but wouldn't it be
useful to handle a separate GRP profile? (or cascading profile).
I mean, the basic profiles are skinny USE-wise and we (i) don't want to
get them hogged... some source-building users mostly want to add stuff
rather than remove, and it's logical. We should add some extras for GRPs
somehow so they can get some goodies/features they lack because of the
USE flags.
Some simple examples could be "alsa", "ldap" or "ipv6".
Just my $.02
Best regards.

- --
Gustavo Zacarias
Gentoo/SPARC & HPPA moncho
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAkGUCV3G/IBCn/JARAuPAAJ0XaMEbPi24A3SN5PEB1TEZo8jbqgCeOG3+
qf40OVG4WfKs746HeiHOxrs=
=iqCf
-----END PGP SIGNATURE-----

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Wed, 28 Apr 2004 23:14:26 -0300 Gustavo Zacarias
<gustavoz@gentoo.org> wrote:
| By this time i may have had more than enough drinks, but wouldn't it
| be useful to handle a separate GRP profile? (or cascading profile).
| I mean, the basic profiles are skinny USE-wise and we (i) don't want
| to get them hogged... some source-building users mostly want to add
| stuff rather than remove, and it's logical. We should add some extras
| for GRPs somehow so they can get some goodies/features they lack
| because of the USE flags.

Hrm, that'd also allow us to lock down to specific glibc, gcc, perl,
openssl, etc. versions just for GRP. That would mostly remove one of the
big problems with GRP as it stands, and move us towards a redhat kind of
model for binaries.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Nathaniel McCallum]

Just a quick perspective from the Gentoo-Installer project... NOT having
a full binary installation for us it not an option.  We ARE providing
users with the ability to use the installer to do a stage one install.
HOWEVER, we should also be able to have a system up and running in under
an hour.  This brings me to a thought I've had for a while: with
genkernel working so well, we should be able to provide binary kernel
packages.  Let me put it this way...

In the ebuild for kernels there should be a flag (unfortunately "build"
is already taken) that once downloading and installing kernel source
code it builds a binary kernel with genkernel.  Then, if you make a
binary package of the kernel ebuild it could install not only the source
but a pre-built kernel as well.  We could then provide a few default
binary kernels with the GRP release.  Eventually, when gentoo tools get
a little better (we may actually work on this as a subset of Gentoo
Installer, we could even auto configure boot info (grub, lilo, etc...).
If this is the case, we could get a full system install into under half
an hour, which would be of GREAT benefit to both desktop users and
enterprise users.

Just my $.02.

Nathaniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Nathaniel McCallum]

I just had another thought... would it be possible to impliment
genkernel as an eclass?  or perhaps split off related functions into a
"library" and have both an eclass and a command line implimentation?

I know I'm thinking big, but it is something that could really help.

Nathaniel

On Wed, 2004-04-28 at 22:25 -0400, Nathaniel McCallum wrote:
> Just a quick perspective from the Gentoo-Installer project... NOT having
> a full binary installation for us it not an option.  We ARE providing
> users with the ability to use the installer to do a stage one install.
> HOWEVER, we should also be able to have a system up and running in under
> an hour.  This brings me to a thought I've had for a while: with
> genkernel working so well, we should be able to provide binary kernel
> packages.  Let me put it this way...
> 
> In the ebuild for kernels there should be a flag (unfortunately "build"
> is already taken) that once downloading and installing kernel source
> code it builds a binary kernel with genkernel.  Then, if you make a
> binary package of the kernel ebuild it could install not only the source
> but a pre-built kernel as well.  We could then provide a few default
> binary kernels with the GRP release.  Eventually, when gentoo tools get
> a little better (we may actually work on this as a subset of Gentoo
> Installer, we could even auto configure boot info (grub, lilo, etc...).
> If this is the case, we could get a full system install into under half
> an hour, which would be of GREAT benefit to both desktop users and
> enterprise users.
> 
> Just my $.02.
> 
> Nathaniel
> 
> 
> --
> gentoo-releng@gentoo.org mailing list
> 
> 


--
gentoo-releng@gentoo.org mailing list

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@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

On Wed, Apr 28, 2004 at 08:32:15PM -0600, Daniel Robbins wrote:
> 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.)

I don't mind if a project is (too) ambitious. If enough developers are
willing to put time and other resources in it, I'm all in favor. It is just
this kind of ambitious projects that makes Gentoo different from the other
distributions. We allow ambition and far-fetched visions to be formed and
developed. 

Many developers will probably see no real opportunity (for Gentoo or for
themselves) in such a project. That's fine, but other developers who do
should get the chance to try and see. Who knows?

Let's just hope that those developers can take a "see, told ye" answer
because they might receive that :)

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On Wed, Apr 28, 2004 at 07:33:36PM -0400, Kurt Lieber wrote:
> There are a number of managers and developers who are concerned with the
> viability/purpose and value of GRP.  At some point, we will need to
> re-visit this and decide if it's in the best interests of Gentoo to
> continue supporting, let alone expanding.

As Daniel stated already, I don't think we will ever get to the point where
GRP will be discontinued in it's current form. Gentoo's always been about
choices and always will. 

I'm not in favor of GRP myself, but I've got sufficient feedback to know
that it's a frequently used aspect of the Gentoo installation. Personally, I
think that developers disliking GRP should just continue with disliking GRP
and doing the job(s) they want and keep the GRP development to the developers 
that are interested in the GRP development. 

Sounds easy doesn't it? :) Unless I'm being totally freaky here (which is
possible as I've drank too much Red Bulls) all this is contained in the
"choices" keyword.

Same discussion goes for genkernel too. 

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-releng] Gentoo 2004.1 Release

[Daniel Robbins]

> Sounds easy doesn't it? :) Unless I'm being totally freaky 
> here (which is possible as I've drank too much Red Bulls) all 
> this is contained in the "choices" keyword.
> 
> Same discussion goes for genkernel too. 

Where do you purchase this Red Bull stuff? Sounds like a great way to
compromise. Choice, choice, choice :)

Regards,

Daniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Thu, 29 Apr 2004 13:40:52 -0600 "Daniel Robbins"
<drobbins@gentoo.org> wrote:
| > Sounds easy doesn't it? :) Unless I'm being totally freaky 
| > here (which is possible as I've drank too much Red Bulls) all 
| > this is contained in the "choices" keyword.
| > 
| > Same discussion goes for genkernel too. 
| 
| Where do you purchase this Red Bull stuff? Sounds like a great way to
| compromise. Choice, choice, choice :)

Sure, it sounds good, but will it ever get off the ground? I'm not
convinced that this idea will take off...

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-releng] Gentoo 2004.1 Release

[Daniel Robbins]

> Sure, it sounds good, but will it ever get off the ground? 
> I'm not convinced that this idea will take off...

OK, we were talking about "GRP" -- the official, current definition here,
which is already off the ground, clearly works, and used by lots of people.
Several years ago, many Gentoo developers were against GRP as it exists
today, and it was a large uphill battle to push for the creation of binary
packages. What we are talking about is whether a possibility exists for
Gentoo to totally regress to that original state, with next to no pre-built
packages were available for our users. At this point, as Sven points out,
there would be a great amount of resistance to GRP being dropped entirely
(many users rely on GRP, the installer project is going strong, etc.)

The stuff in GLEP 26 should be called something else, since it seems like
we're all getting confused about what everyone else is talking about. And I
agree with you in that it may not get off the ground any time soon. This
shouldn't prevent interested parties in trying to figure out how to get it
("it" being binary packages to keep your system up-to-date) to work, though.
And I can certainly understand why infrastructure may not want to host a
comprehensive binary package update repository, since that could potentially
involve a huge commitment of both CPU and storage resources. So huge, in
fact, that it may be technically impossible to do as an official effort
under the Gentoo Foundation itself.

But I think the incremental binary update _technology_ is worth having. A
lot of companies and educational institutions are trying to figure out how
to deploy Gentoo and keep all their machines up-to-date. If incremental
binary package updates are an option for them, I'm sure they'd appreciate
it. Now, I am not saying that _we_ would provide the binary packages to
them. We don't need to host the binary packages -- Gentoo can simply create
the technology, explain how to use it, and then interested companies and
universities can build their own package sets for their own internal use.
Then they have a very efficient way to keep their catalyst-built Gentoo
systems up-to-date.

I bet that a handful will make their binary packages available to the
public. For some organizations, this would be appealing because additional
users would result in more QA over time, more bug reports, and the ability
to improve their binary package sets faster. I think that this is more
likely to happen in an academic setting, though.

Just some ideas...

Regards,

Daniel


--
gentoo-releng@gentoo.org mailing list

RE: [gentoo-releng] Gentoo 2004.1 Release

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]

On Thu, 2004-04-29 at 16:12, Daniel Robbins wrote:
> > Sure, it sounds good, but will it ever get off the ground? 
> > I'm not convinced that this idea will take off...
> 
> OK, we were talking about "GRP" -- the official, current definition here,
> which is already off the ground, clearly works, and used by lots of people.
> Several years ago, many Gentoo developers were against GRP as it exists
> today, and it was a large uphill battle to push for the creation of binary
> packages. What we are talking about is whether a possibility exists for
> Gentoo to totally regress to that original state, with next to no pre-built
> packages were available for our users. At this point, as Sven points out,
> there would be a great amount of resistance to GRP being dropped entirely
> (many users rely on GRP, the installer project is going strong, etc.)
> 
> The stuff in GLEP 26 should be called something else, since it seems like
> we're all getting confused about what everyone else is talking about. And I
> agree with you in that it may not get off the ground any time soon. This
> shouldn't prevent interested parties in trying to figure out how to get it
> ("it" being binary packages to keep your system up-to-date) to work, though.
> And I can certainly understand why infrastructure may not want to host a
> comprehensive binary package update repository, since that could potentially
> involve a huge commitment of both CPU and storage resources. So huge, in
> fact, that it may be technically impossible to do as an official effort
> under the Gentoo Foundation itself.
> 
> But I think the incremental binary update _technology_ is worth having. A
> lot of companies and educational institutions are trying to figure out how
> to deploy Gentoo and keep all their machines up-to-date. If incremental
> binary package updates are an option for them, I'm sure they'd appreciate
> it. Now, I am not saying that _we_ would provide the binary packages to
> them. We don't need to host the binary packages -- Gentoo can simply create
> the technology, explain how to use it, and then interested companies and
> universities can build their own package sets for their own internal use.
> Then they have a very efficient way to keep their catalyst-built Gentoo
> systems up-to-date.
> 
> I bet that a handful will make their binary packages available to the
> public. For some organizations, this would be appealing because additional
> users would result in more QA over time, more bug reports, and the ability
> to improve their binary package sets faster. I think that this is more
> likely to happen in an academic setting, though.
> 
> Just some ideas...
> 
> Regards,
> 
> Daniel
> 
> 
> --
> gentoo-releng@gentoo.org mailing list

Well said Daniel -
GRP is here to stay because it is a user-popular viable install option.
What I proposed in my document are the incremental updates. If we choose
to go this route (which means I would completely rewrite that glep),
then I like the way that Daniel laid out - make the techology available,
document it, and let the users use it if they want to. 

Let me know what you think.

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

On Thursday 29 April 2004 22:12, Daniel Robbins wrote:
> The stuff in GLEP 26 should be called something else, since it seems like
> we're all getting confused about what everyone else is talking about. And I
> agree with you in that it may not get off the ground any time soon. This
> shouldn't prevent interested parties in trying to figure out how to get it
> ("it" being binary packages to keep your system up-to-date) to work,
> though. And I can certainly understand why infrastructure may not want to
> host a comprehensive binary package update repository, since that could
> potentially involve a huge commitment of both CPU and storage resources. So
> huge, in fact, that it may be technically impossible to do as an official
> effort under the Gentoo Foundation itself.

For me, this could best be implemented outside the gentoo project. We could 
then list binary distro's based of gentoo or something like that. We then 
need to add support for better binary dependency checking to portage, but it 
should be possible to pull it off. Full continuously updatable like debian is 
hard though and much of that work should be done by the developers of such a 
gentoo based distro.

> But I think the incremental binary update _technology_ is worth having. A
> lot of companies and educational institutions are trying to figure out how
> to deploy Gentoo and keep all their machines up-to-date. If incremental
> binary package updates are an option for them, I'm sure they'd appreciate
> it. Now, I am not saying that _we_ would provide the binary packages to
> them. We don't need to host the binary packages -- Gentoo can simply create
> the technology, explain how to use it, and then interested companies and
> universities can build their own package sets for their own internal use.
> Then they have a very efficient way to keep their catalyst-built Gentoo
> systems up-to-date.

See above, I agree.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Nathaniel McCallum]

On Fri, 2004-04-30 at 16:32 +0200, Paul de Vrieze wrote:
> For me, this could best be implemented outside the gentoo project. We could 
> then list binary distro's based of gentoo or something like that. We then 
> need to add support for better binary dependency checking to portage, but it 
> should be possible to pull it off. Full continuously updatable like debian is 
> hard though and much of that work should be done by the developers of such a 
> gentoo based distro.

I think it could be implimented in Gentoo, however, the first thing that
needs to happen is frozen trees with only security updates.  This is of
great desireability for our enterprise users.  Once that is done, adding
binary support to that frozen tree is fairly easy.  For instance, lets
say we have a new frozen tree with every release.  So right now the
newest tree would be 2004.1.  We could start by offering just the grp
packages (and their security updates).  A person can always move up
trees (maybe down, but that would be harder) and the highest tree would
be the unstable tree (our current stable tree).  This way there would be
binaries (GRP) on each tree except unstable.  Of course, this is not
continuously updateable as debian is.  However, is can be argued that
continuously updateable is not a "Good Thing" TM.  So to recap, frozen
trees with security updates would be a HUGE step towards a binary based
distro. After the frozen trees all we need to do is expand our GRP
offerings.  BTW, the nice thing about this is that even if a binary
isn't available on your tree, you can still always use good ole source
packages.  AND, if one of the binaries isn't built the way you like,
just rebuild it from source.  What do you think?

Nathaniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Fri, Apr 30, 2004 at 11:16:50AM -0400, Nathaniel McCallum wrote:
> I think it could be implimented in Gentoo, however, the first thing that
> needs to happen is frozen trees with only security updates. 
[...]
> What do you think?

I think http://news.gmane.org/gmane.linux.gentoo.server, more in particular
http://thread.gmane.org/gmane.linux.gentoo.server/687 and
http://thread.gmane.org/gmane.linux.gentoo.server/394

Also see http://www.gentoo.org/proj/en/glep/glep-0019.html

A very hefty topic if I may be so blunt to say :)

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

On Friday 30 April 2004 17:16, Nathaniel McCallum wrote:
> On Fri, 2004-04-30 at 16:32 +0200, Paul de Vrieze wrote:
> > For me, this could best be implemented outside the gentoo project. We
> > could then list binary distro's based of gentoo or something like that.
> > We then need to add support for better binary dependency checking to
> > portage, but it should be possible to pull it off. Full continuously
> > updatable like debian is hard though and much of that work should be done
> > by the developers of such a gentoo based distro.
>
> I think it could be implimented in Gentoo, however, the first thing that
> needs to happen is frozen trees with only security updates.  This is of
> great desireability for our enterprise users.  Once that is done, adding
> binary support to that frozen tree is fairly easy.  For instance, lets

This disregards the quite essential "incremental" feature. 

> say we have a new frozen tree with every release.  So right now the
> newest tree would be 2004.1.  We could start by offering just the grp
> packages (and their security updates).  A person can always move up
> trees (maybe down, but that would be harder) and the highest tree would
> be the unstable tree (our current stable tree).  This way there would be
> binaries (GRP) on each tree except unstable.  Of course, this is not
> continuously updateable as debian is.  However, is can be argued that
> continuously updateable is not a "Good Thing" TM.  So to recap, frozen
> trees with security updates would be a HUGE step towards a binary based
> distro. After the frozen trees all we need to do is expand our GRP
> offerings.  BTW, the nice thing about this is that even if a binary
> isn't available on your tree, you can still always use good ole source
> packages.  AND, if one of the binaries isn't built the way you like,
> just rebuild it from source.  What do you think?

Long way to go to do this right, and some other things probably have a higher 
priority.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Gentoo 2004.1 Release

[Nathaniel McCallum]

On Fri, 2004-04-30 at 17:50 +0200, Paul de Vrieze wrote:
> On Friday 30 April 2004 17:16, Nathaniel McCallum wrote:
> > On Fri, 2004-04-30 at 16:32 +0200, Paul de Vrieze wrote:
> > > For me, this could best be implemented outside the gentoo project. We
> > > could then list binary distro's based of gentoo or something like that.
> > > We then need to add support for better binary dependency checking to
> > > portage, but it should be possible to pull it off. Full continuously
> > > updatable like debian is hard though and much of that work should be done
> > > by the developers of such a gentoo based distro.
> >
> > I think it could be implimented in Gentoo, however, the first thing that
> > needs to happen is frozen trees with only security updates.  This is of
> > great desireability for our enterprise users.  Once that is done, adding
> > binary support to that frozen tree is fairly easy.  For instance, lets
> 
> This disregards the quite essential "incremental" feature.

What do you mean by "incremental"?  Security updates? or
debian-likeness?

Nathaniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Gentoo 2004.1 Release

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Thursday 29 April 2004 21:40, Daniel Robbins wrote:
> > Sounds easy doesn't it? :) Unless I'm being totally freaky
> > here (which is possible as I've drank too much Red Bulls) all
> > this is contained in the "choices" keyword.
> >
> > Same discussion goes for genkernel too.
>
> Where do you purchase this Red Bull stuff? Sounds like a great way to
> compromise. Choice, choice, choice :)

It is some drink from Austria (I believe), it is actually rubbish with an 
overdosis of cafeine in it (much more than European coffee which tends to be 
stronger than american).

Paul

ps. I do like the GRP myself for exactly one reason. Fast setup, I can allways 
recompile everything (I will), but the GRP allows me to have a useable 
machine in the meantime. 

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]