Re: Debian GNU/(k)NetBSD and sparc32 hardware?
On 29/07/2007 16:19:27, Uwe Hermann wrote:
The Debian GNU/(k)NetBSD port may have a lack of people and support
at the moment (I don't know the current status, though).
However, it seems that the upstream development of the sparc32 code
in the NetBSD kernel is _not_ halted (unlike the upstream Linux
Can somebody confirm that? Maybe I'll just ask on the resp.
In that case, a good long-term solution (IMO) would be to bring the
Debian GNU/(k)NetBSD (sparc32) port up to speed (or rather: start it,
I don't think it exists yet, there was only work for i386 and alpha,
That may sound like a lot of work (and it probably is), but I think
it's mostly Debian-related work, and not kernel maintainence work
(as that is done by upstream), so it may be a good option to keep
Debian alive on sparc32 hardware.
I have my opinion to share with you, as a simple Debian user.
I hope not to be boring to you... :)
I believe that support on Linux kernel will halt on old hardware, one
day or another.
Linux still is complete and functional on all platform supported but
some kernel hackers have left or switched to i386/amd64 or other
Please don't label my post as some unuseful critiscism becasuse I
really don't have this intention in mind.
I don't think that dropping legacy hardware support in Linux will be
good or bad, but simply something that will happen.
I remember a public post of one alpha developer giving away all alpha
gear because of total lack of interest in alpha port.
There was also a friend here in Italy, who had a couple of Alpha DS20
boxes and was running an old Redhat.
I tried to be helpful and letting him to switch to more up to date
Sarge some months ago, but a problem with kernel and SMP let him to
Now the SMP problem has been fixed, but it has been long standing issue.
I don't think that legacy hardware support will be dropped very near,
but some day or another it will happen, maybe in the form of a
"linux-legacy" fork, or maybe in the form of a total abandon.
And we have to be prepared for that.
It is not a must, the world will go on even if old machines become
unuseful, but there are many fans and that is a wide target as user
NetBSD kernel seems more willing to last over for aeons (and already
has support for other architectures and flavours like VAX and
alpha/turbochannel among others) but the work of porting debian to
NetBSD is not so easy.
I have tried, and still I'm working on producing something useful on
the NetBSD/alpha front.
At the moment I cannot distribute a full stand alone image, but I have
a Debian chroot for reseach and development inside a NetBSD 3.0
Inside the chroot, there are mainly softwares compiled from Etch
sources and installed "the Debian way" and only a few alien NetBSD
files (less that 50 files in total)
Still, no sysvinit, no runlevel, no networking daemons anywhere.
The main problem in building NetBSD vs Linux packages is the difference
between GNU libc and NetBSD libc and in some difference about
Software which lays on "upper level" is easyier to build (perl for
example compiles smoothly, you only have to remove a few tests from
In spite of my promises on this same mailing list, I still haven't
packaged a tarball of a standalone netbsd-alpha system, and my holidays
are going to be totally spent in Shaolin, China, too far from a working
alpha machine :)
A stand alone booting installation was produced at some time, but on a
faulty RZ29 disk which died short time after.
For those interested into current status, I have rebuilt many packages
a list, and the packages themselves, could be found at:
There are some _all_ arch packages raw imported from ftp.debian.org,
but not too many, only those required to build others.
The work now is on building python2.4 which seems to be required to
build half of packages in Debian Etch.
I have logged everything in a text file (italian speak, but could
translate to the same bad english used in this message :)) what has to
be done to build every package (those that build without changes too).
Just some considerations which may have already been done...
::: NetBSD vs kNetBSD :::
kNetBSD relies on GNU libc, GNU libc is not well integrated in NetBSD
itself and still WIP in NetBSD pkgsrc.
NetBSD libc is already ported to all supported architectures.
I prefer a NetBSD kernel + NetBSD libc port because we already have a
FreeBSD + GNU libc port and producing another with NetBSD kernel as
only difference seems to be a duplicated work.
::: Packaging :::
Looking at the sources, I have found that some work, at some time, has
been done and still could be read in the sources and debian/control.
There are traces inclusion/exclusion of packages in debian/control
"Depends:" lines, knetbsd-i386, netbsd-i386, netbsd-alpha, I also found
a netbsd-mips somewhere.
Since I have found that main problem is GNU libc vs. NetBSD libc I
think that it could be usefule to have a couple of features, if there
are not yet (maybe I don't know how to do, so please explain thanks! :))
1) support for wildcards like netbsd-*, netbsd-%, netbsd-all, or
something like this.
Otherwise if some work is done for netbsd-i386 and netbsd-alpha, every
package has to be checked againg for netbsd-mips and netbsd-sparc and
2) architecture exclusion in debian/control "Architecture:" lines.
Architecture: any [!netbsd-alpha !netbsd-i386 !netbsd-sparc]
Architecture: any [!netbsd-*]
I hope that my post could be useful to Debian platform improvement and
I will report other information as they come, if there is interest in