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

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 support).
Can somebody confirm that? Maybe I'll just ask on the resp.
NetBSD list..

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 "up-to-date" architectures.

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 stop trying.
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 base. 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 installation. 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 networking layer. Software which lays on "upper level" is easyier to build (perl for example compiles smoothly, you only have to remove a few tests from Makefile).

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 so on.
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 it.

Gianluca Bonetti

Reply to: