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
passed).
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:
"${current}/${dir_arch}${images_size}${flavor}rescue.bin"
Which on i386 will look like:
".../disks-i386/current/images-1.44/2_2_14/standard/rescue.bin"
And on a sparc might look like:
".../disks-sparc/current/sun4X/2_2_14/standard/rescue.bin"
The path to `drivers.tgz' is:
"${current}/${dir_arch}${flavor}drivers.tgz"
Eg - ".../disks-i386/current/standard/drivers.tgz"
".../disks-sparc/current/sun4X/standard/drivers.tgz"
The path to `base2_2.tgz' is:
"${current}/${dir_arch}common/base${base_version}.tgz
The actual layout of the tree might look like this:
disks-i386/current
HEADER.html # Maybe only on HTTP mirrors, not CD's?
README
README.html # Ditto - Might have links into subdirs.
md5sum.txt
doc/
dosutils/
loadlin.ext
rawrite2.ext
rawrite2.txt
common/
addons.tgz # Optional - Not totally supported yet. ToDo!
base2_2*.tgz # ToDo: More support for alternate base sets on CD's?
basecont.txt
root.bin # Lets try and make root.bin work with all flavors.
compact/
drivers.tgz
install.bat # Make sure relative path to loadlin is here.
linux
standard/
drivers.tgz
install.bat
linux
images-1.20/
base-*.bin
driver-*.bin
standard/
driver-*.bin -> ../driver-*.bin
rescue.bin
root.bin -> ../../common/root.bin
safe/
driver-*.bin -> ../driver-*.bin
rescue.bin
root.bin -> ../../common/root.bin
images-1.44/
base-*.bin
standard/
rescue.bin
driver-*.bin
root.bin -> ../../common/root.bin
safe/
rescue.bin
[ ... symlinks into ../standard ... ]
compact/
rescue.bin
driver-*.bin
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
thing.
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> ----------------------------------------------------------------
Ross> BOTTOM LINE
The bottom lines are debian/rules and XEmacs.rules. 8-)
--------------------------/-----------------------------
--------------------------.-----------------------------
Reply to: