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

Re: Ideas

On Thu, Jul 01, 1999 at 11:56:47PM +0100, Steve McIntyre wrote
> 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. 
> 

If binary disc 1 has the same packages in each case (and so on) I can't
really see the issue.  People will *see* the non-free/non-US packages, but 
if they know they aren't included they shouldn't be very surprised if they
can't install them; if CD 1 contains all the packages required by the
standard profiles, they need never know the difference as they will never
see a packages list, if they choose a profile and follow the instructions.

>From the number of queries that turn up on the mailing lists, it seems that
at least some people really do have difficulty with the current arrangement;
are you sure that including a full Packages.cd on each one would cause more
problems for end users than it solves?

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

I include apt_0.3.7 compiled for slink on my CDs, and apt-cdrom seems to
sort everything out nicely.  Perhaps a newish apt could be added to
proposed-updates?  Apt-cdrom seems such a natural fit for slink CDs...

>[snip]


John P.
-- 
huiac@camtech.net.au
john@huiac.apana.org.au
"Oh - I - you know - my job is to fear everything." - Bill Gates in Denmark
Reply to: