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

[Nathaniel McCallum]

Pieter Van den Abeele <pvdabeel@g.o> writes:
>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.

Just want everyone to know, that GLIS (http://glis.sf.net) is happy to be
involved with anything that needs help (especially the scripting).

Nathaniel


--
gentoo-dev@g.o mailing list