Re: smarter way to differ architectures needed?
On Fri, Mar 05, 1999 at 05:57:40PM +1100, Brian May wrote:
>
> 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.
This is most certainly not always the case, and it should not be assumed per
se, but linux should be the default (but this is only IMHO, we would have to
look closer at the packages).
> 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.
Right. As Guy said, it is important to have information how many pacdkages
are affected.
Ah, I see now that you have started a catalog below. Let me comment.
> WHAT PACKAGES ARE AFFECTED?
> ---------------------------
[..]
>
> hurd-all (these are hurd specific)
> --------
> (future makedev?)
It is important to see that makedev is arch all, but it should not appear in
hurds ftp directory (as it is right now). We can make a hurd makedev package
if the bug reporting system supports different architectures (hint, hint),
but this is probably confusing, so we should name it makedev-hurd and make
it provide makedev. In fact, the package hurd does contain MAKEDEV right now
and provides it.
But we will certainly have hurd-all packages, like hurd-dev (arch
independent include files), some documentation probably (why clutter up
linux ftp archive with these), and installation stuff (things like pppconfig
fpr hurd).
> (future replacements of linux specific tools that don't get compiled?)
There are some other binary all packages which should not appear in Hurd's
ftp tree, starting from modconf going over to pppconfig and other such
stuff. I don't have a full list yet.
> hurd-any (these are hurd specific, need to be compiled for <arch>)
> --------
> hurd
> hurd-dev
gnumach
> gnumach-dev
> inetutils
> (future replacements of linux specific tools that do get compiled)
Right. There will be more, because these packages need to be splitted.
> 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).
Considering the number of packages, it would be useful to sort such stuff,
so the Linux stuff is not appearing in Hurd archives and other way.
modconf is linux all, pppconfig, too.
> 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
This list is correct, and will probably be extended.
> 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.
Right.
> 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.
Yes! When we have linux i386 binary compatibility :)
> 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.
Yes.
> 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???)
Yes, your description fits well. It would be interesting if such a package
exists, but if you think about extended hurd features, or installation
manuals which are mostly the same, but contain differences for Hurd and
Linux...
> 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.
Couldn't the override file used for that? Guy can probably comment here.
> 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...
Yes, but there is no way around it until we have better support in some
places like BTS for different packages with same name (the source package
name mustbe different, for sure).
> At last... finished... I hope... puff... pant... ;-)
:) Thank you for this summary, it is excellent and to the point. I think you
have shown a lot of places where the new way could be useful, and I hope it
will be implement. Certainly, we can come around the current limitation
for a while, but in the long run it is unsatisfying.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: