[gentoo-dev] Re: The release of 1.4 and its impact on our mirrors

[Pieter Van den Abeele]

On 23/07/03 15:28 +0600, Alvaro Figueroa Cabezas wrote:
> On Jul 23 17:01, Kurt Lieber wrote:
> > On Wed, Jul 23, 2003 at 02:40:39PM +0600 or thereabouts, Alvaro Figueroa Cabezas wrote:
> > > Using jigdo instead of distributing the ISOs.
> >
> > I like the idea of jigdo and think it's a great idea for saving bandwidth,
> > but I don't necessarily see how this will save disk space, which is our
> > primary issue right now.
>
> I must have this wrong. I tought that there where GRP tar files on the
> repository and inside the ISO images.
>
> The stage3 tar file is the stage2 plus a bit more packages, right? Well,
> then this could be manage with jigdo as well. Lets remember that jigdo
> isn't only for ISO images.

The GRP cds can be pre-ordered from our store; they allow one to set up
a complete, optimized gentoo linux *very fast* on a system that shouldn't 
even be connected to the net. These 2 disc GRP sets for each cpu (right now
x86 and ppc, no word yet from sparc or the others) contain (in casu ppc) some 
distfiles, prebuild packages for most commonly used stuff and stages.

A grp cd is a small livecd with some prebuild packages

We know that:

livecd   = bootloader + kernel with uncompressor module + initrd + compressed(live-env)
live-env = stage3 + extra packages
stage3   = stage2 + extra packages
stage2   = stage1 + bootstrap

so we could give you a small script (emerge livecd-ng) that given a 10M
stage1 builds a complete livecd or a GRP cd etc, but that script has a 'I need a net
connection to download stuff' and a 'I need a week compile time, unless you
got 20 machines lying around doing nothing' dependency. 

I think jigdo has the same problem; it has a 'I need a network' dependency.
It might not have a 'I need cpu time' dependency, but we need to make the
prebuild packages available (or have jigdo compile from source). With debian
I can understand those packages are available as .deb, but with gentoo
ebuilds have to be compiled (which is what makes imho gentoo so easy to port
to other platforms/architectures).

I cannot suggest a direct solution to this problem. p2p is the first thing
that comes to mind, but we'll have to look into that first to check if that
solution is applicable to our problem. (safety/security is an important issue
here). 

A solution that I think might be worth while investigating is 'cloning' 
(The idea comes from the prototype-based (instead of OO) programming 
languages, such as Sun SELF):

--
Instead of releasing stages, and several types of livecds on every release,
we could make and release only one livecd for each architecture gentoo linux runs 
on. The purpose of our livecds is to give people an idea what gentoo
looks/feels like when it is installed. So, basically the live environment 
on the livecd == (should be) the same environment as it would be after installing 
gentoo to your hard drive without manually modifying it. The only difference being that the live
environment on the cd is read-only, while those on your hard drive isn't of
course. Since nothing has been manually modified, one can call the live environment
clean. (No user modified files, no user added files, ...)

Portage does merging and unmerging of software: this means
that should you copy a clean live environment from a livecd onto a harddisk,
you could downgrade it to a clean state (stage0), or to a stage2, a
stage3 or just unmerge one package. You could also 'add' or replace software: add an
extra build to the live environment (this requires net connection)... 
Since portage knows what a clean live environment is (it keeps a record of the files it 
installs for each package.), this means that given a 'poluted' environment it should be 
able to migrate to a clean environment. Heck, portage is even capable of given a gentoo
environment, create a GRP package using that environment.

What I'm suggesting is the following: suppose gentoo releases a livecd, and
kept updating the environment on this livecd on a regular interval (mount the
live env, emerge --update word). If we figure out a way to clone the live
environment of a livecd onto a hd, and the other way around, there would be
no need for GRP, nor stages, only a live environment (a livecd). The only thing 
that we need to have is a huge live environment (cd) on major releases and a small 
live environment on smaller releases. I can prove that this cloning system can support
everything we support now (custom CFLAGS...). And we no longer need to
provide people with cpu optimized optimized stuff, as they will be able to
provide that themselves. We could still have an oportunity to build optimized live
environments, but users could do themselves too. (a big environment can be
downgraded to a small one and upgraded to a bigger, optimized one without
much difficulty)

conclusion:

I think that instead of releasing a livecd (=stage1+extra stuff) with a set 
of stages (stage1 , stage1+extra stuff, stage1+bootstrap+extra stuff) and some extra
stuff as GRP cd. We could release a big livecd (=stage1+a lot of extra stuff)
if we enhanced our package manager. I see no drawbacks, apart from revising
our current method of installation. Imho installation stays as educational
and powerfull as it is now. Maybe faster and better to some.
Note that this is only a idea, and not ment to be something that I absolutely
want. 
--

Pieter

-- 
Pieter Van den Abeele
Gentoo Linux                            http://www.gentoo.org/~pvdabeel/

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF238673E
Key fingerprint = F29C C550 54CD 1196 6723  EDC3 9B0D 4EA7 F238 673E