Re: [gentoo-releng] GameCD's and Installation ability

[Pieter Van den Abeele]

Hi,

Networkless installs are still possible by just copying the entire 
'live environment' onto the harddisk and then boot into that. It is 
even possible the other way around: Copying a hard disk install back 
onto a cd/dvd, ... (that's exactly what catalyst does btw).

The problem with jigdo is that it requires a network connection to 
download the different parts that make up the iso, so it only fixes the 
problem for people having for instance a windows box with a cdwriter at 
work they can use to build their jigdo'ed image. (We also need a 
windows maintainer of the jigdo code)

A server side solution would imho be better: have a user declare 
requirements, submit them to a build cluster, which sends the user the 
iso(s) by regular email or makes it availabe for download.

Pieter



On 27 May 2004, at 19:06, Kurt Lieber wrote:

> On Thu, May 27, 2004 at 12:36:38PM -0400 or thereabouts, John Davis
> wrote:
>> How does gentoopix obviate GRP? One of the installation cases that we
>> have to keep in mind is networkless installs.
>
> I don't agree with this assessment.  Gentoo as a whole is almost
> iron-bound
> to some sort of network connection, preferably a fast one. Security
> updates, new package upgrades, etc. all require a network connection.
> You
> can work around this with things like emerge -f, but the same can be
> said
> for networkless installations.  If we're truly concerned with
> supporting
> networkless installations, then I'd suggest looking at something like
> Jigdo[1] which will allow us to custom-build ISOs with source tarballs
> of
> necessary packages.  Debian has used this with great success.  Either
> way,
> supporting networkless installations should not be linked to having to
> provide binary packages.
>
> The primary (only?) reason for GRP is to offer fast installs.  The
> primary
> (only?) reason to support fast installs is to minimize the amount of
> downtime on a user's computer while they're waiting for things to
> compile.
> With Gentoopix (and as soon as someone comes up with a better name,
> I'll
> start using that), you have *zero* downtime.  It's actually less
> downtime
> than with GRP.  You start the Gentoopix CD which presents you with an
> X-based environment, replete with browser, email client, file manager,
> etc.
> You start your installation like you do now and, once the compiling
> starts,
> you have a rich, full-featured graphical environment available to you
> while
> you wait.
>
> If we had the user do some partitioning first, we could even allow
> them to
> store stuff (email settings, browser settings, files, whatever) on the
> HDD
> while waiting for their "real" operating system to finish up in the
> background.  This would allow the user to fully-configure their email
> client and browser settings while the compile was still going and,
> once it
> was done and they booted to their "real" installation, all of their
> preferences and settings would be maintained.
>
> Gentoopix solves all of the same problems that GRP does, but it comes
> at a
> greatly reduced cost.  There are far fewer QA headaches, build time,
> bugs,
> mirror resources, etc required for Gentoopix than for GRP.
>
> This also allows us to have a greater separation between the
> installation
> part of Gentoo and the "main" part of Gentoo.  The install team can
> work at
> their own pace, implementing features that are important to that
> project
> without requiring time or resources from the larger body of Gentoo
> developers.  Right now, we have to freeze trees, synchronize on
> versions of
> catalyst, create package lists, debug build problems with GRP sets and
> a
> number of other minor issues that arise as as result of GRP.
> Obviously,
> there still needs to be close coordination between the two groups, but
> they
> do not have to be linked at the hip in order to coordinate a successful
> release.
>
> --kurt
>
> [1] http://atterer.net/jigdo/


--
gentoo-releng@g.o mailing list