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

Re: Proposed directory structure for the installation "disks"

 [ X-Posted to debian-cd to get your attention...       ]

 [  Please: let's keep this thread on debian-boot.      ]
 [  That will make it easier to follow in the archives. ]

>>>>> "Ross" == Ross Boylan <RossBoylan@stanfordalumni.org> writes:

    Ross> I think the current file arrangements under main/disks-i386, along with
    Ross> the readme, are unnecessarily cryptic.  That is, it's not clear what
    Ross> files one should get.  Here's an alternative proposal.  I know this is
    Ross> a bit late, but I think this is a very important area: it's people's
    Ross> first exposure to debian, and it determines whether they will take the
    Ross> next step.  

 You're just in time with this.  Today I sat down to finish up what I
 started with the changes needed for the new layout.  Perhaps I will
 redo some of what I started...  I will certainly postpone this
 another day or two as this.  Writing this email has caused me to
 rethink it some.  I will for certain need to make a few changes to
 what I have now.

 Should I branch a `br_exp_dirheir' and commit so everyone can have a
 looksee?  It will be tomorrow before I do that if yous want me to
 create an exp branch.  If I don't branch, it may be several days
 before I have it ready for commit to the trunk.  Right now things are
 certainly broken to peices.  It would be good to branch anyway, just
 for the security of having a backup of it on cvs.debian.org.

    Ross> I think it will be clearer if I state the principles first.  However,
    Ross> you may find it easier to skip to the bottom to see what it all means.

    Ross> PROPOSAL 1: Clear the top level directory of material "used for some
    Ross> installation methods."

    Ross> This could be done by changing the readme to provide specific
    Ross> information about when those files are needed (that is, a
    Ross> documentation change would eliminate the offending, unhelpful phrase
    Ross> "used for some installation methods").  However, if I
    Ross> understand, most of these files are for installs from hard disk.  So

 Ok; sounds good, provided that what you say under *Warning below is
 implemented; that is; when someone downloads the images and browses
 to them with the directory browser, they shouldn't need to have
 created a directory structure matching that of the ftp archive.  It
 should look at the toplevel of the directory you enter, then try to
 find things in subdirectories that match the ftp archive's layout.

 We do need to update documentation...

    Ross> PROPOSAL 1a:  Create a subdirectory for hard disk files, and populate
    Ross> it appropriately.
    Ross> So along with images-${size} (disks-${size} before Randolph's
    Ross> proposal) there would be a directory called hard-drive (or perhaps
    Ross> images-hard or images-big).  It would get base2_2.tgz, drivers.tgz,
    Ross> install.bat, linux, loadlin.exe.

 Not quite what I had in mind, but almost.  See what yous think of this.

 ARCHIVE_LOCATION is in "dbootstrap.h".  I have serious changes that
 effect this proposal in "main.c:setup_image_names()" and
 "dbootstrap.h", as well as "release.sh" and some of the toplevel
 "Makefile".  If/when I branch I'll branch all of dbootstrap, and the
 files "release.sh" and "Makefile" at toplevel.  I'll tell yous after
 I do it.  (Can we get commit logs back to the list please?  Is there
 REALLY a threat of symlink attacks on va.debian.org?  In reality?  I
 promise not to "exploit" that bug if everyone else with login access
 there will promise also.)

 Let `current' = ARCHIVE_LOCATION = "dists/potato/main/disks-${arch}/current"

 On sparc, (and perhaps on others) there are sub-architectures.

   Let `dir_arch' = "sun4X/"  # Or whatever...

 On i386:

   Let `dir_arch' = ""

 There are several sizes of floppy disks on some arch's, but not on
 all.  On some there is only one size of floppy disk.

   Let `images_size' = One of "images-2.88/", "images-1.44/",
   "images-1.20/", or "", &c.

 Perhaps there will eventually also be "images-z.ip" or
 "images-ls.120"?  Doesn't `mkisofs' or `mkhybrid' have a bootable
 format where you can use a larger image than a 2.88 floppy image???
 Some people could put a large `root.bin' onto a Zip or LS-120 disk.
 An `initrd' could make that the `/' filesystem for a graphical
 installer, perhaps... (new thread here - defer for Woody)

 For the standard kernel, either passed in via the kernel command line
 (an "append" in syslinux.cfg) or the empty string (no flavor arg

   If flavor == "", Let `flavor' = "standard",
   else Let `flavor' = One of "standard", "compact", "safe", &c.

 `flavor' may contain any valid filename characters excluding
 whitespace and '/'.  DOS 8.3 compatibility is prefered but not
 totally required. (right? and what about Mac?)

   Let `flavor' = "${flavor}/"

 The path to `rescue.bin' is then going to be formed using a sprintf,
 and will look something like:


 Which on i386 will look like:


 And on a sparc might look like:


 The path to `drivers.tgz' is:


   Eg - ".../disks-i386/current/standard/drivers.tgz"

 The path to `base2_2.tgz' is:


 The actual layout of the tree might look like this:

   HEADER.html       # Maybe only on HTTP mirrors, not CD's?
   README.html       # Ditto - Might have links into subdirs.



     addons.tgz      # Optional - Not totally supported yet. ToDo!
     base2_2*.tgz    # ToDo: More support for alternate base sets on CD's?

     root.bin        # Lets try and make root.bin work with all flavors.

     install.bat     # Make sure relative path to loadlin is here.


       driver-*.bin -> ../driver-*.bin
       root.bin -> ../../common/root.bin
       driver-*.bin -> ../driver-*.bin
       root.bin -> ../../common/root.bin

       root.bin -> ../../common/root.bin
       [ ... symlinks into ../standard ... ]
       root.bin -> ../../common/root.bin

 Support for MULTIPLE_KERNELS (and kver_suffix) has been 86'd in favor
 of "flavors".  I will ensure that the flavor name may contain any set
 of valid filename characters excluding whitespace and '/'.

 It could be "2_2_15-standard", for instance... though that will break
 8.3 compatiblilty, but WTF cares anyway, once you've got Linux to
 install.  You can call it anything you like, burn a floppy with it,
 boot, and no more 8.3 for eons long uptimes.

    Ross> PROPOSAL 1b: Create a utility (floppy-utility?) subdirectory.
    Ross> It would get rawrite*.  

 This has already been done as things stand right now in CVS.

    Ross> It would be nice to put links to these files under each of the floppy
    Ross> directories so people can get one-stop shopping.

 Question - If I put that CD into a DOS machine, will the symlinks
 work?  All of the filenames are 8.3 now, except for the doc's; but
 I'm not sure about symlinks.  I guess to read docs they'll most
 likely be in Windows anyway, so there's long filenames unless they
 still run Windows 3.1 or something.

    Ross> If the directory is called utility one might put install.bat here too,
    Ross> rather than under hard-drive.

 Hmm; No, AFAIK the install.bat files vary.  The command inside them
 depends on which version you are booting and where this particular
 `install.bat' is located relative to "loadlin.exe"...

 Uhhmmm... Now I'm not sure of something (BION).  What is PWD for that
 `install.bat' when you double click on it in Windows?  Is that how
 they launch it?  Or do they have to go to DOS mode for it?  How does
 it find `loadlin.exe'?  Do they have to set up PATH?  (I guess if
 they don't even know how to set PATH yet...  never mind.)

    Ross> This would leave the top level with a readme, basecont.txt, and
    Ross> md5sum.txt.

 Ok...  I'm planning to put base2_2.tgz and a few other things into a
 "common/" subdirectory.  Is that alright?  And again, I think that
 `root.bin' ought to be a common; it should not depend on which
 rescue.bin it's used with.  (This will cut down the `boot-floppies'
 build time by quite a lot also.)  Who will take on this chore?

    Ross> ---------------------------------------------------------------
    Ross> PROPOSAL 2: If flavors are present, treat the regular install as just
    Ross> another flavor.

 That will be done, as you've seen above.

    Ross> The goal here is to clarify that people interested in the flavor do
    Ross> not need the "regular" files in the directory above, and that people
    Ross> who want the regular files do not need the flavor subdirectories.  I
    Ross> think the latter is currently more obvious than the former.

 Files common to all flavors will be in the parent directory of the
 flavor directories.  There will be a directory called "standard/".

    Ross> The material currently under flavors at the top level would go to an
    Ross> appropriate subdirectory (of utility or hard-disk I suspect).

 No.  Each flavor has its own `install.bat' program, AFAICT.

    Ross> -------------------------------------------------------------
    Ross> PROPOSAL 3: Provide a clear way for people who wish to switch media to
    Ross> do so.

 Like, put buttons on the disk drives that make them eject?  Cool!

    Ross> Concretely, this means people who want to start the install from
    Ross> floppies and switch to hard drive or network ASAP.  I think the recipe
    Ross> is something like "get floppy specific files *excluding* the base
    Ross> files.  Get the base image and loadlin from hard-drive."  But perhaps
    Ross> things are not simple?  

 The README ought to say that all you need is to 1) RTFM
 "installation" 2) download the right sized rescue.bin, root.bin, and
 drivers-*.bin. 3) Network fetch the rest.  (and in unusual
 circumstances, blah blah blah, use floppies for base, &c.)

    Ross> * Do different flavors need different base images or "linux" files?

 Different `linux' kernels for sure.  "base2_2.tgz" is common to all
 flavors.  "root.bin" currently is NOT, however, and I would like to
 remedy that somehow.  Can it be done?  I have not researched that
 yet.  I'm new around here.

 I want to create a CD with a custom "base.tgz" on it for easy/quick
 installations of fully loaded and half-ass-configured [type of
 machine].  Some documented and easy to use support for doing that
 within the `boot-floppies'/`debian-cd' framework would be a great

    Ross> * Does one need files beside base2_2.tgz?  For example, in my installs it
    Ross> seems to read the drivers.tgz file from disk, even though I've
    Ross> previously fed it the diskette.

 It assembles the diskette(s) into a {drivers,base*}.tgz file, and
 extracts that using zcat | tar x.  If you use the "compact" flavor
 and you're lucky enough to have a network card whos driver has been
 built into the "compact" kernel, you can net-fetch or NFS install the
 drivers, OR if you are installing from a CD or filesystem, it will
 grab the drivers.tgz file itself; no need for floppies.  Once you've
 installed the drivers, you can configure the network and fetch the
 base*.tgz via http (ftp anytime soon?  ETA?) or NFS.  Otherwise,
 you'll pull it off a CD or filesystem.  Only in rare cases on old
 equipment will the floppy-split base become necessary.

    Ross> * Warning: you need to put the file in a directory hiearchy which
    Ross> mirrors that in the archive up to potato.  (I gather this is the case
    Ross> now, though it would be nice to eliminate it).

 Yes, that would be a good thing.  This is RC, IMO.  We should not
 expect people to have to try and set up the similar heirarchy like
 that.  What a pain.  And Mandrake has this and Red Hat has that and
 Caldera has the other thing.  Linuxconf this and linuxconf that.  We
 can't stand for that!  (We thank Red Hat Software for at least Newt,
 surely.  It doesn't hurt to borrow the best of what we find in the
 other Freeware OS distributions.  That's what it's all about anyway.)

    Ross> Aside from documentation, one might create an alternate route into
    Ross> directory structure which was based on stage of installation as the
    Ross> top level.  That would use links.

 Nah.  Unless you show me what you mean, within the directory
 structure I show above, perhaps as ammended by the `boot-floppies'
 and `debian-cd' crew as we discuss this...

 If there are two logical paths into a subdirectory that are a
 different number of `/' levels deep, relative links pointing back out
 from there are ambiguous.  Therefor, there MUST NOT BE any symlinks
 to `.' under here, or we won't know how many levels deep we are for
 relative links pointing back up.  The symlink debian -> . works at
 the top of "/instmnt" (base dir of CD) only because there are never
 any xdev symlinks in there right now.  Perhaps this would become an
 implementation detail issue for a setup with a live filesystem on the
 CD that needs links out to a ramdisk.

    Ross> ---------------------------------------------------------------
    Ross> PROPOSAL 4: The top level readme should explain what the different
    Ross> flavors are for.  (This is pretty independent of the other proposals).

 Ok, that's obvious enough.  All of our documentation is going to need
 a week of very busy revision after we get this all nailed down tight
 enough to stand on.

 The various kernel images need to have better description paragraphs
 in them I've noticed.  There's one called "-ide" and I have no idea
 what that is.  The description is completely generic.  There is no
 indictation of the difference between the standard kernel and the
 flavored ones.

    Ross> ----------------------------------------------------------------

 The bottom lines are debian/rules and XEmacs.rules.  8-)

Reply to: