`boot-floppies' <current> directory structure spec.
[ Follow up to `debian-boot@lists.debian.org' please. ]
>>>>> "J" == J A Bezemer <costar@panic.et.tudelft.nl> writes:
>> Anne's proposal is very nice, though at this point I'm a little unsure
>> whether links are OK for the CD.
J> They should be. If the sym2hardlink stuff doesn't work (which I really doubt),
J> we'll just manually copy all files. AFAIK there's enough space left on the
J> 3 Binary CDs to store that.
They are NOT going to work. Symlinks are part of the rockridge
extensions, which is unsupported by DOS. `mkisofs' doesn't preserve
hard links either; it copies the file anew. (Even though files that
are hard linked to two file names on the hard drive show a link count
of 2 on the isofs, it does not support hard linking.) If you try to
hard link one file to another, it will work on the hard drive or ftp
site, but NOT on the CD; there it will take twice as much space for
two links, three times as much for three, &c.
_That_ is why the directory was laid out the way it was. We cannot
change it after all, in the way I had thought we could, or we'll end
up with too many copies of base-*.bin on the CD, wasteing quite a lot
of space. (The room we'll need for a graphical installer, or vendor
addon's, perhaps.) It's a choice between having either of...
base2_2.tgz
flavorA/
drivers.tgz
images-1.20/
rescue.bin
root.bin
drivers-*.bin
base-*.bin <------- Once
images-1.44/
rescue.bin
root.bin
drivers-*.bin
base-*.bin <------- Once
flavorB/
drivers.tgz
images-1.20/
rescue.bin
root.bin
drivers-*.bin
base-*.bin <------- Twice.
images-1.44/
rescue.bin
root.bin
drivers-*.bin
base-*.bin <------- Twice.
... OR ...
base2_2.tgz
images-1.20/
base-*.bin <------- Once.
flavorA/
rescue.bin
root.bin
driver-*.bin
flavorB/
rescue.bin
root.bin
driver-*.bin
images-1.44/
base-*.bin <------- Once.
flavorA/
rescue.bin
root.bin
driver-*.bin
flavorB/
rescue.bin
root.bin
driver-*.bin
flavorA/
drivers.tgz
flavorB/
drivers.tgz
It's obvious that the second layout takes up less space on the
CD-ROM, by (the size of the 1.20Mb base disks) + (the size of the
1.44Mb base disks). If all OS's that need to read the disk supported
symlinks, then either one would work just as well as the other.
I get the feeling I'm rediscovering something that the person who
designed the current layout already knew or discovered while
designing that layout. I will document this someplace; in a comment
in "utilities/dbootstrap/main.c" near where the image locations are
set up would be a good place for that, I think, and all other
locations in the code where this is important should refer to that
comment "fyi".
So, the layout will look something like this... (which is pretty much
what it already looked like before we started all this.)
Let me know *SOON* if you see anything majorly wrong with this
layout! I will be coding all afternoon *TODAY*. I will be on
irc.debian.org in the #debian-boot channel. (I plan to take a short
break after mailing this, then to begin working on `boot-floppies'.
I have to go look for a part-time job (waiter?) tomorrow so I can
pay my bills. I'm $400 short this month.)
All architectures will have this common set of files and
directories... (I may forget a few files, but at least I can show the
general outline even if a _few_ details are missing.)
Let : --> == LHS is a symlink pointing to RHS.
<pkg_version> == The Version: field from `dpkg-parsechangelog'
<build_date_iso8601> == The build date in iso8601 format separated by periods.
disks-<arch>/current --> <pkg_version>-<build_date_iso8601>
disks-<arch>/<pkg_version>-<build_date_iso8601>/
HEADER.en.html <--- for the Apache generated directory; make it look pretty.
HEADER.??.html <--- translated into all supported languages.
README.en.html <--- HTML for Apache directory footer.
README.??.html
README.en.txt <--- formatted text generated from the HTML.
README.??.txt
doc/
index.en.html <--- Short index page; see CVS. Link to Acroreader @ Adobe.
index.??.html
<documentation files>
<BASE_TGZ> <--- currently "base2_2.tgz"
basecont.txt || base-contents.txt <-- DOS 8.3 || POSIX filename.
<ADDONS_TGZ> <--- vendor supplied "cruft"; optional, not fully supported yet.
The subdirectory layout that differs between architectures will vary
from one architectures to another with the values of 3 variables.
Let :
<subarchs> == a list of short subarchitecture identifier strings.
OR the Empty list.
(eg: sun4u, sun4c, ...)
<sizes> == a list of diskette image size strings.
OR the Empty list.
(eg: 1.20, 1.44, 2.88, ...)
<flavors> == a list of <flavor_name>'s.
OR the Empty list.
(eg: standard, safe, compact, ...)
<flavor_name> == Name of flavor, spelled out, _matching_ the
corresponding kernel-image-<kver>-<flavor>.deb
_if_ that exists.
Let : <_path> == The deepest path where a file may reside; the
place for non-common (most specific) things like
the "rescue.bin" and matching "drivers-*.bin".
Let : <== == Assignment from RHS to LHS
+ == String concatenation infix operator.
+<== == Assign LHS concat RHS to LHS.
Initialize <_path> <== disks-<arch>/<current>/
If [ -n <subarchs> ] then
foreach <_s_arch> in <subarchs>
thereis <_s_arch>/
<_path> +<== <_s_arch>/
If [ -n <sizes> ] then
foreach <_size> in <sizes>
thereis images-<_size>/
<_path> +<== images-<_size>/
If [ -n <flavors> ] then
foreach <_fl> in <flavors>
thereis <_fl>/
<_path> +<== <_fl>/
Else If [ -n <flavors> ] then
foreach <_fl> in <flavors>
thereis <_fl>/
<_path> +<== <_fl>/
Else If [ -n <sizes> ] then
foreach <_size> in <sizes>
thereis <_size>/
<_path> +<== <_size>/
If [ -n <flavors> ] then
foreach <_fl> in <flavors>
thereis <_fl>/
<_path> +<== <_fl>/
Else If [ -n <flavors> ] then
foreach <_fl> in <flavors>
thereis <_fl>/
<_path> +<== <_fl>/
Let : <_s_arch> <== One of <subarchs> + /
<_size> <== One of <sizes>
<_image_size> <== images + <_size> + /
<_fl> <== One of <flavors> + /
To find an image, `dbootstrap' (main.c:setup_image_names) will
sprintf the value of <_s_arch>, <_image_size>, and <_fl>
respectively into a format string that is just catenated "%s"'s,
the number of "%s"'s depending on how deep into <_path> it needs to
look for a particular file. Remember that each of those may be the
empty string.
Example : i386
"%s%s%s%s", "", "images-1.44/", "standard/", "rescue.bin"
images-1.44/standard/rescue.bin
Example : sparc
"%s%s%s%s", "sun4c", "", "", "rescue.bin"
sun4c/rescue.bin
Etc...
For the Woody Makfile's, the paths will be created by targets that
the files that are to land in them depend on. The file's targets
will be formed by macro expansions and concatenation. So, everything
will get put where it belongs to begin with, and the "release.sh"
kludge can go away once and for all. The Makefile will use `include'
to bring in several modules in "rules.*"'s. It will use ifeq and
${arch} to bring in ONLY the segment for the architecture being built
on.
Karl M. Hegbloom <karlheg@debian.org>
Reply to: