Supportting Linux, Hurd, FreeBSD, etc. (was Re: Stop Debian/FreeBSD)
On Sun, Nov 21, 1999 at 08:53:25PM +0100, Marcus Brinkmann wrote:
> > Well, that's true. But syscall itself is just a libc function.
>
> Yes, but I am not sure if even a subset of the available syscalls are
> standardized across platform anywhere.
We should probably concentrate on the subset of syscalls which are
actually used.
> > > 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.
>
> O'course.
>
> > 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.
>
> I would like to solve the dpkg side of the problem first (because that's the
> issue I am familiar with, and is more close to my direct needs). Frankly, I
> didn't think about the above points at all (except (b) a bit), but if
> necessary they should kept in mind for the complete solution.
> In this scheme, a kernel package would provide virtual packages, which
> define the ABIs exposed at run time, like the syscalls available or the proc
> filesystem. Library packages expose further ABIs. A package is installable
> if it only depends on the ABIs exposed.
Yeah, basically. Maybe, that linux-2.2.13 would Provide-OS: linux,
linux-2.2, and linux-2.2.13, and any binary package could have a
Depends-OS: linux-2.2.
But, there's still the matter of selecting which of several options
to use.
For non-essential, non-performance-critical packages a simple shell
script cover would work. But if /bin/sh needs to be different that
would seem to require a symbolic link set from init.
> > 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.
>
> I think this is not a fundamental problem. The type of kernel in use
> can be autodetected at run time via uname, and beside dpkg's database
> an exception list can be kept for sysadmins who don't use make-kpkg.
Right, but how do you inform dpkg (or apt) that a kernel is going
to be used and we need the corresponding packages?
> > 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.
>
> I am afraid I only have a vague idea of what you mean here. Can you explain
> in other words or probably give an example?
Let's take lsof.
I'm running a linux 2.2 kernel. I've got lsof installed. I'm planning on
switching to another kernel. [I don't care whether it's linux 2.0, 2.4,
hurd, freebsd, netbsd, etc. etc. -- just that it have an lsof available for
it.] I'd like to tell apt to install the relevant support for this kernel
and have it pull down and install the relevant lsof. And, because I don't
want lsof to be unavailable either before or after the boot, the current
conflicts mechanism is unacceptable.
Ok, so maybe apt isn't going to be up to this and we have to write some
other wrapper program to deal with this case.
The basic idea, though, is that we should be able to support systems where
kernel selection happens at boot time, and have things work reasonably.
But perhaps, if essential packages can't support both kernels, that's
an option we'll have to go without. :(
> > 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.
>
> I see. However, it would get ugly, and there are issues with mirroring only
> parts of the archive (no fundamental, though). [luckily, it's also true the
> other way round: The current archive can be put on top of a package pool,
> and provide a smooth transition.]
Yep. "Things getting ugly" implies the need for a change, but we should
be able to do the change without breaking things too badly.
--
Raul
Reply to: