Re: RFC: Better portability for package maintainers
On Sat, 2006-05-20 at 22:45 +0100, Roger Leigh wrote:
> Erast Benson <email@example.com> writes:
> > On Sat, 2006-05-20 at 12:32 -0500, Michael Banck wrote:
> >> We had a pure NetBSD port before, but so far no non-glibc port got added
> >> to the archive officially (but that doesn't mean it would get rejected
> >> if it was of release quality).
> >> IMHO a glibc-based OpenSolaris would certainly be the better and more
> >> interesting option (but might take some effort initially).
> > Do you really believe so? Do you understand that such a "hybrid" will
> > not run any existing Solaris apps like you will not be able to run
> > simple thinks like Macromedia flush player, JRE, JDK, Oracle, SAP, etc
> > etc... Do you still wanna do that?
> Yes, IMO.
> This binary compatibility with Solaris would have the same value as
> the iBCS2/Linux-ABI of yesteryear (that is, have very little value at
> all). The only practical use is to run proprietary Solaris
> applications. That's it. Ten years ago, iBCS on GNU/Linux was a
> useful tool, but today proprietary software runs natively on Linux,
> but more importantly the proprietary software in common use ten years
> ago now has plenty of Free replacements. As a result, iBCS is no
> longer in use; I'm not even sure if Linux-ABI has been maintained for
> the last four years. It's dead.
> I the same vein, I don't believe ABI compatibility with Solaris is
> particularly useful nowadays for a GNU/Solaris port. Let's face it,
> the libc and system call interfaces are only a small part of the ABI
> of an application, and soname revs in all of the other libraries are
> going to make it deviate from Solaris if it becomes part of Debian
> proper. That is, the libc ABI isn't the whole picture for anything
> but a trivial program.
> Having GNU libc and ld.so /would/ be useful, certainly of much higher
> value than limited Solaris compatibility. We would get the same
> linker (and extensions), plus the same libc (and extensions) as all
> our other ports. Having a uniform toolchain across all the ports has
> a number of advantages.
> GNU libc likely does not support Solaris-specific features. This is
> not a reason to not use GNU libc however, but is a reason to add the
> missing features. I understand that glibc was known to work on
> Solaris in the past, so it can surely be fixed up to work with some
> effort. In the long term, having GNU libc on GNU/Solaris is very
> desirable, and I wouldn't call it GNU/Solaris myself until it uses GNU
This is what I call utopia...
Existing API and ABI must be respected, especially when we are talking
about major existing Operating Environments such as Linux, Solaris,
FreeBSD and MacOSX.
If you'd like to produce new OS which is not compatible with anything
and not done clean, go ahead, I'm not going to participate.
Clean way would be to extend SUN C library with missing GLIBC
functionality. Btw, have you seen SUN C library code? Its done very
clean, very polished code base which runs at least on i386, amd64, sparc
and powerpc arches.