Hello :)
Thanks for replying!
> Well that could be, but note the GNU/kFreeBSD port is using a GNU
> libc which help a lot to build Debian package without patches.
I think that the work for "kernel independence" has a positive
influence on the chances of another port to work with little patches.
I could not imagine to do the same thing on a platform other than
Debian!
> Well first you should think about GNU/NetBSD versus GNU/kNetBSD, ie
> using a NetBSD libc or a GNU libc. Both have some advantages, but
> using a GNU libc helps a lot to build Debian packages without any
> patches.
> But that also means some porting work on the GNU libc side
I've chosen the NetBSD kernel+libc approach.
One of the main features of NetBSD is its portability to many
architectures and that would be difficult to reproduce with GNU libc.
The porting of GNU libc in NetBSD pkgsrc is ongoing but still not ready
for use.
> Then I wonder if the choice of the alpha architecture is a good
> choice for now. I have nothing against alpha, but if you are seeking
> for some help, or even some users, i386 would be a lot better. Even
> kfreebsd-amd64 is not really used compared to kfreebsd-i386. Also an
> architecture i386 means that users can try this system in an emulator
> (for example QEMU).
That is a really good point.
At first I started with beta testing in mind, not thinking to be on the
production side.
I supposed that GNU/NetBSD-i386 port was more active than the alpha
one, but I see that there's little demand of both from users, so the
interest of developers has been devoted to other projects.
By now, an i386 port signifies doubling the work for me.
I have time to devote to this project, but I think not to two.
I still consider that the NetBSD port is interesting for those
platforms where Linux has worse or no support, or where the Linux
developers are loosing interest (as seems to be for alpha)
Anyway, I should consider that if I'm doing the work only for myself,
it's a waste of time and that an i386 port would attract more people.
> For the development guidelines, I would say the first goal is to have
> all the essential as well as build-essential packages ported so that
> you can have a clean developement environment. Then you can try to
> setup an autobuilder to get more packages built.
Yes, the building toolchain is the main goal.
It's already done and working, but not deb-packaged.
The autobuilder is a secondary goal for now as the building process
stops very frequently and there are still too many missing libraries to
have automated builds.
> A few tips now. I adive you to take notes of what you are doing. Take
> notes of the ugly hacks you are using for now (or even better avoid
> them), and keep a list of them. It is very frustating when you find
> something is not working due to an ugly hack you have written 1 or 2
> years before and you have forgotten. I also advise you to use a
> version control system to store your patches and your notes, this is
> very useful.
I usually take a journal in a raw text file of things done.
A few times I had to look and see what I did to reproduce the hack,
expecially when repackaging newer versions.
> If you have other questions, don't hesitate to ask them.
>
> Cheers,
> Aurelien
Thank you very much for the support!
Bye
gl
--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org