On Sun, May 19, 2002 at 02:59:34PM +0200, Marcus Brinkmann wrote: > * Some issues in the Hurd itself. We are working on them of course. Things > like missing features that some packages need, etc. I mention them up > front because nobody needs to think that just fixing the Debian related > issues will lead to a fully functional Debian GNU/Hurd system atomatically ;) Yeah I know I should hack pthreads! ;-) > * There are packages like makedev, which are specific to GNU/Linux and > binary all. They appear thus in the Hurd archive. OTOH, there are > packages that are tagged as binary any in debian/control, but which are > really Linux specific. Of course, it can also be the other way round > but there are much fewer Hurd specific packages right now, and we usually > just give them the hurd-i386 arch tag and be done with it (works for now) > So, we need to improve the architecture handling in Debian, to make a > finer distinction between operating systems GNU/Linux, GNU/Hurd and BSD > flavors etc. Wichert has plans for this, it is going slow, but it seems > that at least everybody is aware of this now. > > This is a difficult problem btw! Don't underestimate the work needed to > fix this, it comes with a lot of hair. I also know a person who comes with a lot of hair and is a problem sometimes and we are dealing with him for years. :-)) It's not that it is impossible, but you've to be willing to. I'm glad Wichtert is. > * We have a symlink from /usr to ., and would like to see X to be installed > in /, too (either by applying a similar symlink /X11R6 or by just setting > the prefix). This is actually technically necessary, because our linker is > ELF and ELF only, and only looks in /lib for libraries. Other work > arounds would be setting rpath (policy conflict) or, when it is available > runpath. The /usr symlink messes up fewer things than you would think. > One thing it messes up is dpkg-shlibdeps, but we are actually working on a > fix now. > > The amount of work needing to fix this is: fix dpkg-shlibdeps for us, and > put X into / (by symlink, whatever). If I remember correctly Branden said that he would deal with the X11R6 issue after woody. > * The Hurd likes it a bit differently and more GNUish than GNU/Linux. > For example, we have another top level directory /hurd that is not > accounted for by the FHS, and we want to use /libexec at least for > the Hurd itself. That is not much of a huge technical issue, more like > a policy conflict. Will be taken up at the appropriate level (hopefully > FHS). > > Policy issue without lot of technical difficulties, at least for us. > The BSD people are going to care even more about /libexec if the runtime > linker is installed there, I guess! I looked and RedHat still has the /usr/libexec so I wonder why Debian can't be. > * Of course, still many packages need porting! Often there are just minimal > changes necessary, like movng from sys_errlist to strerror, or from termio > to termios. The Hurd drops a few of the very old and attic UNIX interfaces > if there is a more modern and better replacement. Also, we don't have > some of the limits like PATH_MAX, and packages relying on that need > fixing. This is of course a problem that has to be taken up again and > again with individual packages, and the experiences are mixed. However, > in almost all cases, it is not an issue at all, just normal porting work. > > This work is endless :) but I think for the limited resources available > to us we are doing quite well. Before the ABI change, we had about 45% of > the Debian packages compiled, and tihs percentage does not take into > account Linux specific packages we can't compile (so the actual percentage > out of packages we theoretically can make to work is a bit higher, so I > guess we have more than the half already) But we only require POSIX compatible changes, I believed that wasn't clear for at least somebody. The only POSIX incompatible change I know of is canonicalize_file_name(), but as my fix to POSIX is accepted and glibc is already changed we should actually start to change those packages back to the POSIX interface. It's not that hard because because canonicalize_file_name(name) is now just "return __realpath (name, NULL);" with glibc. We just need to test whether the implemention returns EINVAL or malloc()s and then define the code according to that. Jeroen Dekkers -- Jabber ID: jdekkers@jabber.org IRC ID: jeroen@openprojects GNU supporter - http://www.gnu.org
Attachment:
pgpQYtf1Oin5n.pgp
Description: PGP signature