[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

  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...


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: