Re: Debian GNU/(k)NetBSD and sparc32 hardware?

[Gianluca Bonetti <gl@decadence.it>]

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,
> IIRC).
>
> 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.
>
> Comments?

Hello

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:

http://decadence.boldlygoingnowhere.org/debian/dists/etch/main/binary-netbsd-alpha/

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.
Like:
Architecture: any [!netbsd-alpha !netbsd-i386 !netbsd-sparc]
or
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.

Bye
Gianluca Bonetti