Re: Diffs between Linux, the Hurd and *BSD ports of Debian - constructiveness
Grzegorz Prokopski wrote:
This is one reason why I've held off trying to merge in patches for
freebsd-i386 until after woody is released.
I have been following recent discussion about the Hurd closely - under
"where do NEW packages go" on both d-d and d-hurd lists (not all was
crossposted, so you surely missed some if didn't read both lists).
From what I have seen there I think that direct cause for all the
1. Bad timing Woody release, and ABI switch in the Hurd - for both
"so-called" groups these are *extremly* important things.
Lack of information isn't necessarily the problem. I'd guess lack of
interest is worse.
2. Lack of information - so that "the rest" (non-Hurdish) part of
Debian Community had a chance to learn how, where and why the Hurd
There are three BSD porting efforts. So that would make 5 OS ports. The
three BSD's are quite similar to each other, and have similar issues,
but aren't exactly the same.
As there's not much that can be done about the first issue
(anyway I hope the packages needed for the Hurd so badly will be put
into the archive shortly), the second one seem much more important in
a long run - in the future.
It seems that we (Debian) may have three ports in not so far future:
- the Hurd
That's not necessarily why there's lots of flames. It's quite possible
to understand the issues just fine and draw wrong conclusions.
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).
So what I am trying to propose here?
I imagine that it would be good for Debian (as a whole) and Hurd
and *BSD port too to put up a complete list of DIFFERENCES that
MAY be needed to take into account when creating Debian ports.
For every difference there should be complete description:
- what is exactly the difference,
- why is it there (what for),
- pros and contras of changing it to fit current (surely Linuxish!)
- how would it affect other ports (does it force maintainers to do
some additional work, etc),
- others that matter
Are you volunteering to maintain such a list?
Bear in mind that for the BSD ports, most of the differences have
nothing to do with Debian Policy. I think the only policy violation I'm
aware of in freebsd-i386 is having /usr/libexec/ld-elf.so.1. Possibly
the use of /usr/bsd for the BSD tools I need to build the kernel and
libc violates FHS as well, but it'd be trivial to move it, if I can
figure out where to put it.
However, there are things that are in glibc that are separate libraries
on BSD. So I have libiconv and libshadow packages, and if you need to
use one of them, you'll have to link to it.
I've got a small problem with /usr/libexec: FreeBSD puts its dynamic
linker there. While I could move the dynamic linker to /lib, it would
break binary compatibility with regular FreeBSD, which I'm reluctant to
do without a stronger reason. At the moment, it's possible to run Debian
GNU/FreeBSD in a jail on a regular FreeBSD box, and it would also be
possible to do the reverse. I think that's useful to preserve.
I belive that would be good starting point of the discussion
(which will of course happen after Woody release) about the changes
in the Debian (which must come anyway) and how new ports should
best fit into (new, improved) Debian (Policy).
I have no enough knowledge to start such a document, even if I am
interested in the Hurd. I have only heard about some things like
/hurd /libexec vs. FHS or MAXPATHLEN problem - but I am sure there's
more to _disucss_.
But other than that, I have no need for /usr/libexec.
Depends. I believe all three BSD ports are using native libc's, while
the Hurd shares glibc with Linux. (If anyone wants to port glibc, let me
know. ;-) That mostly causes nuisenses when packages assume glibc.
From what I was told - many of the differences that the Hurd has
(compared to Linux) will also be true for *BSD port.
Maybe joining the forces here would help.
I try to minimize differences as much as possible. A lot of packages
just work, since a large part of Debian is portable software. The rule
of thumb seems to be that the more essential a package is, the more
problems I have with it. :-(
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org