RE: Proposed directory structure for the installation "disks"
Thanks for this very useful information. I was about to say it would be
good if we could provide "one-stop shopping," so that people would only need
to go to a single directory to get the files they needed (by picking media x
flavor). That would not work so well if we can't use links. (although the
amount of extra disk space would not be that great).
So maybe the new recipe needs to be to descend the directory hierarchy,
picking up all files in each directory as you go.
On another point (Karl's): if you click on install.bat in windows explorer,
I'm pretty sure the file runs in that directory.
I think a user is looking for the easiest way to identify and then get the
files s/he needs. In Karl's proposal there is a separation between diskette
images and other things. I would actually put anything relevant under the
appropriate dir.
So instead of
common/
compact/
standard/
images-xxx
[flavor]/
dosutils/
doc/
I'd go with
media-xxx/ #media, not images, since it may have non-images
[flavor]/
hard-drive/ # media-big? media-hard?
loadlin.exe
addons.tgz # when ready
base2_2.tgz
root.bin # if it can be made common
[flavor]/
dosutils/ # as above, less hard-drive specific ones (loadlin.exe?)
doc/
I think (but I'm not absolutely sure) that the top level flavor directories
in Karl's scheme all belong under hard-drive/ in my scheme, along with
/dosutils/loadlin.exe and the files listed under common/ (again, not sure,
but aren't they just for hard disk based install? isn't it built into the
diskette images for the other methods?).
Anyway, my confusion illustrates my point (!). It needs to be crystal
clear, hopefully even to people who don't RTFM, which files they need to
get. Karl's proposed top-level scheme mixes 2 principles: flavors and disk
sizes. Echoing Anne's point, (and her criticism of my earlier proposal), we
should keep one principle at work at each level of the directory.
In fact, we could take things one step further:
basecont.txt
md5sum.txt
readme*
doc/ # we could even eliminate this, putting all doc material at top
hard-drive/
# as above
floppy-drive/ # 8.3 problems..... maybe use hard/ and floppy/
rawrite*
media-xxx/ # as above
> -----Original Message-----
> From: J.A. Bezemer [mailto:costar@panic.et.tudelft.nl]
> Sent: Wednesday, March 01, 2000 11:47 PM
> To: debian-boot@lists.debian.org
> Cc: Ross Boylan; debian-cd@lists.debian.org
> Subject: Re: Proposed directory structure for the installation "disks"
>
>
>
> On Wed, 1 Mar 2000, Karl M. Hegbloom wrote:
>
> [...]
> >
> > 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.
>
> Didn't read the entire posting, but some remarks about links:
>
> 1) Windows doesn't recognize symlinks on the CDs, so should not
> be used for
> install-related files. (binary-i386 -> binary-all is okay
> because people
> won't see that at all.)
> This also means that the documentation should not refer to
> _any_ symlinked
> files/directories -- this includes /disks-*/current/ !
>
> 2) Hardlinks on CDs are supported on all OSes, but not for FTP
> mirroring, so
> should not be used at all in the main archive.
> At the moment, on CDs there is a <cd-root>/install/ dir with
> hardlinks to
> most files in disks-i386/; this is done by the CD creation scripts.
>
> 3) Without the proper documentation, 2/more paths to the same
> thing cause many
> problems for first-time users. They see two versions of the
> same thing, but
> "which one should I take??" This is especially weird if those versions
> differ at some points like the 2.1rX /install/ and disks-i386/.
>
> Possible solution would be that the CD creation scripts hardlink
> /install to
> whatever directory disks-*/current is pointing to. (Does it do already??)
> But then the documentation (preferably top-level README, either
> in the CD root
> or in /install/) should clearly mention the fact of the
> "replicated" directory
> (CD-only feature, not on FTP).
>
>
> Regards,
> Anne Bezemer
>
Reply to: