[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ideas

Martin Schulze writes:
>Steve McIntyre wrote:
>> I was talking to Ian last night on the way back from the Linux99
>> conference about the current state of the install process, especially as
>> it relates to multi-CD. We came up with a couple of things:
>> 
>> The problems people are having with the multi-CD install could be helped
>> in a very simple way. (I assume that people have noticed confused posts to
>> debian-user.) People are not seeing the README on each disc that explains
>> about inserting the last binary disc first for Update in dselect. I'm
>
>First of all I'd like the authors of slink-cd to READ and UNDERSTAND
>the readme that comes with dpkg-multicd.
>
>To be precise it says:
>
>  contain all `Packages.cd' files.  To be more convenient you should
>  include the `Packages.cd' files on all CD-ROMs.  This ensures that
>  you don't have to start with the first CD-ROM all the time.

Yes, I read this a long time ago and understood your reasoning. And I'm no
longer convinced by it - see below. 

>If the authors of slink-cd would have placed the .cd files on *all*
>affected disks as it was proposed, the users won't have complained.
>
>Please copy the additional Packages files around and place them on
>every affected cd into a proper directory.

There _are_ .cd files on all disks. But they are not the same. I'm sure I
must have explained why before now; I'll try and be clear this time.

Originally, slink_cd used the multicd method as suggested - copy the
Packages.cd files around onto every disk in the set so the user could just
Update using any of them. This is non-optimal for a couple of reasons:

Do we put the .cd files on the source discs as well, or just the binary
discs? If we put them on the source discs we make them architecture-
specific. OK, easy choice. No Packages{,.cd} files on the source discs. 

The really awkward case is the one that really decided me: how do we cope
with different sets of binary CDs? In the case of people wanting to be
able to distribute the following sets: 

   binary #1                       (demo CD, to give away at shows etc.)
   binary #1,#2                    (full main binary distribution)
   binary #1,#2, source #1,#2      (full official set)
   binary #1,#2, source #1,#2, non-free/non-US #5
                                   (full official set, plus extras)

This scheme would mean people having to maintain *eight* different and
incompatible CDs - count them. This is a nightmare for people trying to
sell Debian CDs, and an even worse one for people mirroring the images. 

With the current multi-cd layout, the optimal way IMHO is to go the way I
chose: the Packages.cd file on each binary CD knows about the contents of
itself and any previous binary CDs, so (using the example above): 

   Packages.cd files on binary CD#1 list packages on CD#1
   Packages.cd files on binary CD#2 list packages on CD#1 and CD#2

   (source disks don't contain Packages files at all)

   Packages.cd files on binary CD#5 list packages on CD#1, CD#2 and CD#5

Then the user is told to run the Update step in dselect using the last
binary CD. This _is_ a problem, admittedly - the instructions are not made
clear enough. That's why I've suggested adding a simple message to the
multicd update code to make sure people can't miss it.

>> going to patch the dpkg-multicd method to insert a message in the Update
>> step itself, so people should now no longer be able to miss this. And to
>> fix the other source of confusion, I'll also add a warning that in many
>> cases a simple install will never use any disks subsequent to the first
>> one... 
>
>I would appreciate if I - as the current maintainer and quartor-author
>of dpkg-multicd - would be informed before something is done.  Thanks!

Don't worry, my "patch" above would have been by email to you as the
maintainer of multicd. :-) I'm not trying to tread on any toes here... 

>Apart from that, this is the wrong way - imho.  Please put the .cd files
>on all disks.  If people don't like multicd they can still use the
>regular cdrom method and use the regular Packages files.

Which is by now almost useless IMHO. The moment we split the main section
across multiple disks, the standard cdrom method failed us. It's no longer
much use at all. But in case people still want to struggle along with it,
the current CDs have usable "normal" Packages files in the right places
too...

What we need is a better CD-ROM interface that asks the user to feed all
their CDs in in turn and remembers the different Packages files from each.
This is clearly the best way to do things IMHO. If I understand his code
at all, this appears to be what Heiko is doing with dpkg-multicd V2. And
IIRC it's what Jason is programming apt-cdrom to do also. Then we can get
away from the problems I've detailed here with multiple CDs. It also gives
us more freedom to do what some people have been pushing for for some time
now - producing a core CD and splitting the other packages off onto extra
CDs organised by section/priority/vendor interest. Debian is getting too
big for much else...

And we can then go for the extra cool stuff on CD#1 that has already been
mentioned: 

  Live filessystem with space to have a real linux system up and running
  from it, either as a demo or as a rescue system. Allow the user to
  compile their custom kernel at installation time using this...? Maybe
  do something similar to Lasermoon a few years ago and let the user run
  almost everything off CD, only copying stuff to the hard drive as
  necessary / prompted? That was a _very_ cool feature for new users...

  Graphical installation - obvious

  Maybe (pie in the sky) a single install CD common to all architectures?

Clearly we still need to maintain boot-floppies for non-CD installations,
but it's time to start putting the extra space available on CD to good
use. 

Comments?

>> that Ben (Collins? Gertzfield?) has done a lot of work on a framebuffer
>
>Pfaff.

Oops, I can never remember names well. Apologies, Ben... :-(

-- 
Steve McIntyre, Cambridge, UK.                   stevem@chiark.greenend.org.uk
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer
Reply to: