Re: Stop Debian/FreeBSD
Hi,
On Sun, Nov 21, 1999 at 09:05:29AM -0500, Raul Miller wrote:
> 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.
Yes, but I am not sure if even a subset of the available syscalls are
standardized across platform anywhere.
> Also, I'd like to point out that most of the debian packages which are
> being rebuilt for freebsd aren't calling syscall.
Indeed.
> > 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),
In the Hurd it would be a translator in user space (translators are programs
providing a filesystem, and are attached to an inode). The information can
be either as close to the running system as possible or "bogus" (just to
satisfy the querying program), depending on what you need.
However, any solution we aim for should be usable for many architectures
with differently complete emulation layers. (Of course only as much as
feasible).
> 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).
Yes, an interesting point.
> 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.
Okay, I see where you are aiming at, and your list below makes it even more
clear. You are trying to solve a slightly different, but related, problem than me.
I was still thinking of traditional installations: One kernel/OS and a bunch of
applications. The problems here are specifying which packages can be
installed or build on which kernel/OS and for which OS we need to rebuild
the package.
You are going one step further and ask which underlying kernels can be
installed simultaneously.
> > 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.
About (a): A naive aproach would simply be to let the sysadmin install
the packages wanted. All kernels installed provide their own ABIs, and
you may end up with a Hurd package and a Linux package installed.
Interesting situation, and I think (c) above would be quite important to
solve run time problems.
Example for (c): start-stop-daemon, once using the Linux procfs, once
using the Hurd libps.
> 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.
Mmmh. I was just going to propose the infamous shadowfs on the Hurd :)
I think ultimatively installing all packages in their own tree and unioning
them all together is an excellent approach, at least in theory. It lets you
install several versions, leaving the ultimate choice to the user, and
solves some nasty other problems quite elegant. Anyway, we are far from that
anyway (several years).
> 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.
> 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?
[...]
> > 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.
It was never meant to address these points. The questions I was asking is:
How can we specify on which systems can a package be installed?
For which systems can a package be build?
And in conclusion: For which systems does the packag need a rebuild?
Whatever we do about (a) and (c), we must solve the problems inherent to
these questions. Solving them first and getting experience with
multi-platform binary packages for some time might be a good idea.
> 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.
You are right, the issues are hairy. But I am not going to spend significant
time on these issues (more than I did at least), without some help and the
feeling that eventually a good solution will be implemented. Up to now, only
the Hurd port was affected, and although flourishing, there are only few
people actively involved. I know the help of the admins and further people
is needed to develop a good and complete solution, and so it will only
happen if enough people feel it is worth the work.
> 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.]
Seems this is enough stuff for a whole bunch of new threads... are enough
people interested working on those problems? I know they are important for
the Hurd and BSD port. But from your perspective, also for Linux wrt kernel
compatibility. So maybe enough people are affected and interested, if only
we can address enough issues at the same time.
Thank you,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: