smarter way to differ architectures needed?
IMHO:
A clean solution is required; one which Debian will not regret in the
future.
This is how I interpret what I know about the situation; please
feel free to correct any mistakesssss... ;-)
FTP LAYOUT
-----------
Looking at the problem from a different perspective to Marcus; the
ftp layout. Many people will already know this, however, I think
it helps to spell it out in full.
Currently the ftp site of slink is organised in this manner
/debian/dists/<dist>/<section>/<type>-<arch>/<subsection>/
Where
<dist> = {...,hamm,slink,potato,sid,...}
<section> = {main,contrib,non-free,...}
<type> = {binary,disks}, will assume <type>=binary in this mail.
<arch> = {all,i386,m68k,sparc,powerpc,arm,alpha,...}
<subsection> = {base,...}
The <arch>=all is a special case. It is usedby all other
arhitectures (currently, I think symlinks are used).
However, everything here assumes that only one OS will be used.
Support is required for another field, <system>, eg
<system> = {all,linux,hurd,etc}
In sid this is already done this way:
/debian/dists/<dist>/<section>/<type>-<system>-<arch>/<subsection>/
This isn't the only way it could be done, however I don't
see anything wrong with this approach, so I will assume it
will the one will continue to use.
For completeness, another completely different approach could look like:
/debian/dists/<dist>/<section>/<arch>/<type>-<system>/<subsection>/
this would allow downloading all files associated with a specific <arch>
more easily, for instance, if somebody wanted to mirror multiple systems
on his/her computer/cd of a given <arch>.
eg: this would allow all linux specific files to go into:
/debian/dists/<dist>/<section>/<type>-linux-all/<subsection>/
Similarly, this would allow all hurd specific files to go into:
/debian/dists/<dist>/<section>/<type>-hurd-all/<subsection>/
Also, any files (I think grub might be one) that is independant
of the OS kernel can be supported, eg:
/debian/dists/<dist>/<section>/<type>-all-i386/<subsection>/
(Note: This is different to what is currently implemented for linux
on slink or potato, but I think it is better not to have any
one OS system as a special case.)
I don't very much like the current technique of using symlinks
to point to <arch>=any (this would need to become a <system>-<arch>
combination). I think as most people use apt these days, it might
be better just to get apt to automatically look in the correct
directory. If the required information is not listed in Packages
(ie <system> and <arch>), then IMHO, it should be. apt
should then be able to reconstruct all of the required information
to get the full path without symlinks (it might already do this,
I'm not sure).
PACKAGES
--------
Marcus suggested
(a) changing the package architecture type into the
form "<arch>-<system>". I would prefer the form
"<system>-<arch>" myself as it is more consistant with the
FTP structure of sid.
(b) One field for <arch> and another field for <system>.
(c) Is suboptimal, and as described above, I think it will be regretted
later on. It involved using "<arch>" and "<system>-<arch>", but
without supporting <system>=any or <arch>=any, hence every combination
has to be manually entered.
(Sidenote: For source packages, <arch>=any is also supported;
Supporting <system>=any is probably also a good idea, see below
for affected packages. )
I think that both schemes are much the same, they both specify
the same information, and don't care which one gets used.
If the value of <system> doesn't exist, just assume "any" (for
<arch>=any) or "all" (for <arch>=all) or "linux"(???) depending
on the value of <arch>. I suggest adding a warning if the
<arch> is hardcoded without and <system> specified, as it
is not clear what <system> are supported. Can it be assumed
that the only reason a specific <arch> is supported is because
the package contains assembler code, hence will run on other
<system>? Maybe this is not always the case.
BTW: Don't ignore the fact that in the future, a package might work with
multiple, but not all <system>, eg makedev might run OK with Linux and
netbsd but not hurd (any comments, flames, suggestions regarding this
assumption or netbsd to >/dev/null please).
In this case, it would be easy to support with either method, eg
(a)
Architecture: linux-any netbsd-any
(b)
Architecture: any
System: linux netbsd
I think it is wise to support this type of thing from the very start,
even if it is not used in the immediate future, as it is a lot easier to
do it now then later.
I say again: I do not see any benefit of using (a) over (b) or (b)
over (a), except if you want to use "-" in the name of the
<arch> or <system>, but you will encounter other problems here
anyway.
WHAT PACKAGES ARE AFFECTED?
---------------------------
Just a quick list: others may want to make modifications.
Based on the list of packages I currently have installed. I haven't
double-checked any of this, I might have mistakes.
Some of the examples for potential packages in certain sections could be
better, I haven't put much effort into thinking them out.
<system>-<arch>
--------------
template for below
hurd-all (these are hurd specific)
--------
(future makedev?)
(future replacements of linux specific tools that don't get compiled?)
hurd-any (these are hurd specific, need to be compiled for <arch>)
--------
hurd
hurd-dev
gnumach-dev
inetutils
(future replacements of linux specific tools that do get compiled)
linux-all (these will not work under the Hurd).
---------
kernel-source-* (??? does Linux compile on Hurd? Is this desirable??)
kernel-package (OR linux-any, not sure).
linux-any (these will not work under the Hurd, need to be compiled for <arch>).
---------
kernel-image-*
syslinux
makedev
netbase
login
strace
smbfsx
tcpdump
ttysnoop
ppp
ppp-pam
quota
(+other firewall, networking, ppp utilities)
sysklogd
statserial???
lilo
all-all (these will work under any <system>-<arch>).
--------
All packages that currently have <arch>=all, except those
listed above. None of these have to be compiled to run on a different
system kernel.
all-any (these will work under any <system>-<arch>, but need to be
compiled for <arch>)).
--------
grub (NOTE: grub doesn't need to be recompiled to run on
a different <system> (at least I don't think it does),
hence it uses <system>=all, not <system>=any.)
any others??? I don't think lilo can boot hurd, or I would put
it here too. However, lilo can boot other OS besides Linux.
documentation that needs to be "compiled" for the architecture
might go here (maybe something on low level assembler code,
could be parsed/selected during package build to give correct
documentation for that architecture?)
any-any (these will work under any <system>:<arch>, need to
be compiled for a specific operating system)
--------
All packages that currently have <arch>=any, except those
listed above. All of these have to be compiled to run on a different
system kernel.
any-all
--------
(probably no packages fit into this catagory. These packages
would need to be compiled for the <system> but not the <arch>.
Perhaps <system> specific documentation, parsed/selected at
package build time, for the given <system> may fit here???)
LIMITATIONS
-------------
1. I have not address one very important issue: What happens if one
<system> requires a package in <subsection>=base, or with
different priority then another <system>? eg grub is essiential
for hurd, but not required for Linux, as many people use still
use lilo. I think more of these issues might exist, but I can't
think of any right now.
2. It is highly likely that certain packages, eg ppp will have
to be redesigned to work on the hurd. Currently, it looks
like these packages will have to have another name, which
might be messy...
At last... finished... I hope... puff... pant... ;-)
Brian May <bam@snoopy.apana.org.au>
PS: Please CC all replies too me; I am not yet subscribed to this
mailing list.
Reply to: