Re: where do NEW packages go?
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
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: