Re: "Official CD" screwups (Was: Why only one non-free section?)
On 16-Sep-1998, Joseph Carter <knghtbrd@earthlink.net> wrote:
> On Wed, Sep 16, 1998 at 01:11:33PM +1000, Tyson Dowd wrote:
> > May I suggest that there be an official file on the CD which simply
> > gives the location of the relevant Packages files on that CD,
> > and a description of each one. This file should live on the root
> > directory of the CD, and have a standard name.
>
> THIS is an excellent idea, though I am probably going to suggest a couple
> things that might break dselect without apt be done with it.. =< I think
> you might like the ideas though, they will generally be helpful.
>
> Then again, it might be worthwhile to make it (dselect and methods) support
> this too, it'll be faster and easier for people to handle or make sub
> distributions of, designed to fit a zip disk or whatever. (This would make
> me happy because it would greatly simplify my zip project--which has NOT
> been abandoned, just put on hold a little while till someone versed in
> initrd's can help with the design)
Well, the problem is that it has complex dependencies, and apt is
the only tool that seems to be up to the job at the moment. The
apt method of dselect should handle most situations (and with some
tweaking it might be able to take over the role of the other methods
anyway).
>
>
> > Installation tools can parse this file, and present the user with a
> > list of possibilities. For example:
> >
> > CD Label: Vendor Y Debian GNU/Linux 2.0 Disk 3
> >
> > Packages: debian/hamm/contrib/binary-i386/Packages
> > Description: Packages from the contrib section of Debian 2.0
> > These packages ... blah blah blah.
> >
> > Packages: debian/hamm/non-US/binary-i386/Packages
> > Description: Packages from the non-US section of Debian 2.0
> > These packages ... blah blah blah.
> >
> > Packages: extras/binary-i386/Packages
> > Description: Vendor YYY packages, including product X.
> > Product X .... blah blah blah.
>
> I was thinking more like ...
>
> ----8<-----------------
> CD-Label: Cheap*Bytes Debian GNU/Linux v2.0 (hamm) Disc 1
> Vendor: CheapBytes
> # P.O. Box 2714 Fax: (209) 367-8518
> # Lodi, CA 95241 Email: sales@cheapbytes.com
> # U.S.A. URI: http://www.cheapbytes.com
> # This stuff is not actually used anywhere, just handy for vendors to put
> Version: 2.0 (hamm)
> Alt-CD: Cheap*Bytes Debian GNU/Linux v2.0 (hamm) Disc 2
> Alt-CD: Cheap*Bytes Debian GNU/Linux v2.0 (hamm) Disc 3
>
> Distribution: main debian/dists/hamm/main
> Description: whatever
> Archs: binary-i386 binary-all
> Sections: admin ....
> .... web
>
> Distribution: ......
> :
> :
> ----8<-----------------
>
> And then there's the package files... I suggest doing that just a LITTLE
> differently...
>
> in the main dist above, you'd have things like..
>
> debian/dists/hamm/main/pkg-lists/Packages-admin_binary-i386.gz
>
>
> Seeing my idea in print, it needs refining, but this would allow us to break
> up dists into multiple CDs the way we had to break source up for hamm. It
> would ALSO allow us to have non-CD distributions.. Zip disks, Shark disks,
> anything in theory big enough to hold the biggest section you want to
> include. That's another thing, you wouldn't have to include ALL sections
> this way if you were making something like a Zip disk and wanted to keep it
> down to a minimum of what you'd actually need.
>
> I was hoping the above would do that, but it's really too unrefined to be a
> solution now. Refinements welcome.
That seems ok (in general, obviously it needs to be fleshed out).
One final idea that springs to mind is that it should be possible to
have a "first" CD that describes a bunch of other CDs, so you
don't have to insert 5 CDs to get them registered.
In other words, you can have packages files that correspond to
different discs. There is little reason why a scheme with an
index like above can't cope with this.
> > Insert a CD, ask apt to scan it, and it will present a list
> > of package lists, you select the ones you want to add to your sources,
> > it will add them, and when you want to install them, it will prompt
> > you to insert the CDROM labeled "Vendor Y Debian GNU/Linux 2.0 Disk 3".
> >
> > This allows us to provide "update" CDs, specialized distribution CDs,
> > add-ons, and have a management system (you can even remove sources at a
> > later date if you no longer have the CD).
> >
> > FTP sites and the like can be handled in much the same way.
>
> Was hoping to expand that to partial mirrors, partial/minimal distributions,
> etc. I find the giant Packages.gz file for main kinda annoying if all I
> wanna see is if there's a new <whatever> yet. Or for example, I could care
> less the contents of games sections..
>
>
> > (This system is kind of similar to the Windows driver installation
> > system, although hopefully we can avoid the constant "where is your
> > Win95 CD, where is your driver CD, where is your Win95 CD..." routine).
>
> possible-devices: /dev/hdc /dev/sdb /dev/sdc /dev/sde
>
> Program scans each of them looking for what it needs, gets it, then tells
> you what it doesn't have yet. Of course, if you have other methods tried
> before this asks you, but hey.
The important thing is it needs to try to order the media to minimize
swaps. Partially, this is the job of the media creator (you don't
spread "base" across two discs if possible). Partially, it is the
job of the tool (try to minimize swapping -- copy .deb files in advance to
a temporary area if possible). A good strategy might be to group
applications with their libraries.
We are going to have to solve this problem anyway, because slink
will probably spill onto a second idea, so it would be a good time
to add a few features so that it can be expanded to multi-disc
distributions in general.
--
Those who would give up essential liberty to purchase a little temporary
safety deserve neither liberty nor safety. - Benjamin Franklin
Tyson Dowd <tyson@tyse.net> http://tyse.net
Reply to: