Re: Stop Debian/FreeBSD
On Sun, Nov 21, 1999 at 02:41:13PM +0100, Marcus Brinkmann wrote:
> syscalls are a different issue. Software using syscalls can be declared
> as such, and only installed on systems that provide such syscalls or an
> emulation.
Well, that's true. But syscall itself is just a libc function.
Also, I'd like to point out that most of the debian packages which are
being rebuilt for freebsd aren't calling syscall.
> Compatibility at a library API level is not a problem for the Hurd, syscalls
> are, as well as use of the proc fs.
Well, it's certainly possible to emulate the proc fs (either at the
library level or, by re-implementing the relevant parts of it at the
kernel level), but I can understand wedding procfs dependent code
to a certain architecture. But note that we have analogous problems
even within linux (take a look at lsof for example).
And, it's very true that we're not solving this very well at the moment.
Taking lsof as an example, try setting up a system where you can boot
either a 2.0 kernel or a 2.2 kernel and expect lsof to work.
> Of course, seperation at this level is not possible at all with the Debian
> architecture scheme. I often explained how Depends: could solve this
> problem with virtual packages, but this would be of course a bit more
> complicated to implement :)
>
> But what we can do is to declare packages as linux-any if syscalls or procfs
> are used.
I suspect your Depends: system would be closer to the mark.
But the boot process is outside the scope of dpkg. So it comes down to
the sysadmin to decide what kernel instances are available, and there
should be
(a) An easy way for the sysadmin to declare what kernel versions are
usable on the current system to dpkg. [equivs could be used, but I
think it's wrong to use a subsystem which rightly declares itself as
"a crude hack" for something so fundamental.]
(b) A way of selecting from a set of architecturally different but
equivalently named packages based on this information.
(c) An alternatives mechanism which can pick the right executable at
run-time, based on the kernel in use.
Note that the FHS is a step in this direction, but it conceives that there
would be a completely distinct file system hierarchy (with /usr/share/
shared among these). For the case of different "architectures" which
run on the same processor we need something that can be restricted to
the significant packages.
And, I think we're going to have to do without a union fs for our
solution, because file system configuration is also well outside the
scope of dpkg.
> > (2) Once that emulation is reasonably complete -- such that any remaining
> > problems are obviously kernel related -- the simple thing to do is make
> > the freebsd kernel depend on (or recommend, for optional/extra/non-us
> > packages) any relevant freebsd specific packages.
> >
> > Hopefully, there won't be too many unessential packages pulled in using
> > such a scheme.
>
> I think you are thinking the wrong way about it. Dependencies are
> top-bottom, not bottom-up.
I understand completely.
However, kernels are really outside the scope of dpkg. dpkg can't install
them in the typical case, and all too often they need to be rebuilt which
means that dpkg is not informed of what kernels are present.
Even more important, if we make a kernel-based distinction about packages,
we lose the information about what packages the user has selected.
In principle we might be able to work around this using virtual packages,
but unless we do something horrible with Conflicts: a person still
wouldn't get the relevant packages on installing a new kernel.
> > It's true that brute force workarounds should be replaced with something
> > more elegant. And I hope that the hurd and freebsd people can come up
> > with such a thing.
>
> I can come up with a scheme, but not implement it. Then there is the
> blockade of the ftp admins, mirror admins, and the Debian policy group.
> That's too much hassle for me to go through for me, especially as I can't
> provide a finished and ready-to-use implementation.
>
> The scheme I have in mind would work bets with the package pool idea.
>
> Please see http://www.debian.org/~brinkmd/arch-handling.txt
> it's a bit old, but the core reflects still my idea.
This looks like a step in the right direction, but it doesn't seem to
really address points (a) and (c), above. And, it's not even complete
to itself. I think these are much more significant obstacles than
anything about our network of admins and mirrors being conservative.
Note also that the package pool idea *can* be built on top of the current
ftp file system architecture using symlinks. The pool concept doesn't
care where files are stored. There are some constraints about package
versions (we don't keep distinct versions of the same package within a
distribution), but that's a quality issue, not an architectural issue.
Thanks,
--
Raul
Reply to: