Re: where to but the disk images and tarballs
On 22 Nov 1999, Adam Di Carlo wrote:
> Bruce Sass <bsass@freenet.edmonton.ab.ca> writes:
>
> > platform/special/subarch/format
> >
> > where...
> > "platform" is one of: alpha i386 m68k powerpc sparc
>
> This is irrelevant -- all the stuff is already in 'disks-<platform>'.
ok. disks-<platform>... 6, or half a dozen, in my book.
> > "special" is for stuff like alt-kernel-version
>
> Yeah -- optional.
>
> > "subarch" is a set:
>
> Optional.
Not really, every platform except i386 has sub-arches.
> > # i386
> >
> > safe
>
> This is special, not arch.
see below
> > # sparc
>
> sun4u and default. How to deal with that?
as a sub-arch(s).
I noticed that slink had three sets of sun disk images, two of them had
&alt-kernel-version; in the file names... I just hadn't gotten around to
determining if potato would have different sets or not.
> > "format" is one of: tgz 2880 1440 1200 720
>
> Ew. I don't like this ... for one, tgz should remain 'common'. I
> just don't like tgz.
Neither do I, the point was to emphasize structure, the actual names
used can be anything (I'd rather use "files", since "common" implies
that the files in it are needed for every installation).
> > So, you would find the files needed to setup a Miata box files under:
> > alpha/miata/1440/{base-{1,2,...},driver-{1,2,3},root,rescue,boot}
> > or
> > alpha/miata/tgz/{base,driver,root,rescue,boot}
>
> You forget the extension.
Nope, I left them off. ;)
> > and for i386:
> >
> > i386/safe/1440/...
> > i386/alt-kernel/1440/...
>
> Keep it 8.3.
of course
> > i386/alt-kernel/1200/...
> > i386/alt-kernel/720/...
> > i386/alt-kernel/safe/1440/...
> >
> > Are there any disk images or tarballs that will not fit under this
> > scheme?
>
> I like my scheme better. It's similar. I do like the way you have
> special and subarch broken out. Let me reformulate my scheme:
>
> [special/][subarch/]format/file
>
> To recast your i386 example:
>
> common/...
> disks-2.88/...
> disks-1.44/...
> disks-1.20/...
> safe/1440/...
> raid/disks-1.44/...
> raid/disks-1.20/...
> raid/safe/disks-1.440/...
Hmmm, this is two `specials'...
although it is not the reason I had classed "safe" as a subarch,
it is the kind of thing I wanted to allow for.
Technically, yes, safe is a special, but what would you call it if it
was only one manufacturer's box that required the safe option...
What it boils down to is that a sub-set of boxes out there have special
requirements; whether those requirements arise because the mfg hung
different chips off the bus, uses a different OS, or a slightly broken
floppy drive (this is safe, as in the `safe, slow and stupid' floppy
driver option, right) is not important.
So, for all practical purposes, safe can be treated like a sub-arch
(but only because the i386 platform is the only one that needs safe,
clearly this would not work if every arch under alpha also had a safe
version).
Plus, doing otherwise would throw a wrench into my attempt at automating
the generation of url entities for the docs.
> cmdfoo/disks-1.44/...
> cmdfoo/disks-1.20/...
> cmdfoo/safe/disks-1.440/...
>
> Rationale:
>
> format should have 'disks-' prefix to show it's a format, not a
> subarch.
>
> common is common to lots of possibilities
So that's where it comes from. ;)
> keep dir tree as shallow as possible
I tend to agree, except in this case where clarity is more important,
IMHO.
> retain 8.3 compat w/o causing non degerate OS's to suffer
Having more directories to drop things into could mean that less
information needs to be encoded into the filename;
would that help with 8.3 compatibility?
later,
Bruce
Reply to: