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

Re: Ideas



On Thu, 1 Jul 1999, Steve McIntyre wrote:
[...]
> 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.

As a Debian CD vendor, I must say I like this scheme very much. It allows me
to make a third Binary CD (non-free/non-US) that is completely compatible with
the first two Official Binary CDs. For the documentation says "insert the last
Binary CD" which is (in this case) my Extras CD.

In the case that the Packages.cd files are identical on the first and second
Binary CDs, it gets far more confusing. For then the docs on the Official CDs
should be like: "insert either one of the Binary CDs; but if you have a
unofficial vendor-supplied CD, insert that one instead." Try to explain that
to a newbie. (Which is BTW the correct spelling, according to the Jargon
Lexicon.)

In my Dutch Debian manual, which I ship along with CDs, I've indicated how
multicd works. I've received no complaints whatsoever. Instead it gives the
idea that there's been "a lot of thought" when creating the CDs, as Debian is
fully useable in a consistent manner with either 1, 2 or 3 Binary CDs.

BTW, I think it's possible to put Packages.cd files on source disks. IIRC,
these files are in the binary-ARCH/ subdirs. On my Extras CD, I simply
included all binary-*/ subdirs, empty except for the Packages.cd files which I
copied from CD#2. This way, my non-free/non-US CD is useable for all
architectures (and includes source). This method should also work on
"source-only" CDs -- but I would strongly advise against it. It would again
make things far too complicated. 

[...]
> >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...

Does the cdrom method still scan all files on the CD? If so, it's totally
useless and even people with only one CD should use the multicd method (or
apt of course).

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

Possibly. But then we've only got 1/4 or 1/5 of the space left for all those
nice binary packages. Which means that 1-CD-give-away-versions probably won't
give the correct idea that "Debian has _very_ much packages".


Regards,
  Anne Bezemer


Reply to: