W liście z nie, 19-05-2002, godz. 14:32, Grzegorz Prokopski pisze: [...] > Most of the developers is familiar with the first one and have no > time to dig around to learn more about the others. That's why there's > so little understanding of all the issues here (and lots of flames). [...] > For every difference there should be complete description: I am replying to myself as in that "flammable" thread I found the answer to this mail. I belive it COULD GET LOST easily, as I don't expect every DD to read all the mail in that thread. So below is what Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote. I asked him to repost it here and he suggested I do it so... I belive it is a must-read for any DD ;-) Read on! ************************************************** On Sat, May 18, 2002 at 11:14:04PM -0400, Eric Dorland wrote: > Could you perhaps outline what exactly are all the problems the > GNU/Hurd port is having right now. I don't follow debian-hurd and I'm > sure a lot of other developers don't. I think we're all scratching our > heads wondering what exactly are the technical problems being faced by > it, and less interested in all of the rhetoric. CC debian-hurd because of relevance ;) I think Grant Bowman is working on such a list. It probably won't be complete. I have some personal things on my agenda, however, I am not sure they are strictly related to this thread (but who could know what is related to this thread and what not. It has certainly spawned some interesting and constructive subthreads for me). Let me wrap up some of the essential technical or policy issues that have (well, most of them) to be solved before Debian GNU/Hurd can be released: * 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 ;) * 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. * 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). * 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! * 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) * Many people in the Hurd are strong supporters of GNU, and the free software philosophy. As such, we would like to not have non-free software in Debian GNU/Hurd of course. The DFSG is a tiny bit more relaxed than the GNU definition of free software. The number of packages free within DFSG and non-free by GNU shrunk to a selected few recently, but potentially the difference is there (for example, the original Artistic License is DFSG free, but not GNU free). Not sure what to do about this, it's a policy issue, which could probably be solved by technical means. I am sure many here will not really agree with me on that it is an issue at all, but I mention it for completeness, because I care about this. This of course is a highly sensitive issue. That's what comes to my mind spontaneously. Is this about what you expected as a reply? I am not sure how much of this really has to do with the thread... Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de
Attachment:
signature.asc
Description: PGP signature