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