On Wed, Dec 03, 2003 at 02:16:04AM +0100, allomber@math.u-bordeaux.fr wrote:
> Dear debian-bsd folk,
>
> [disclaimer: I am just a random Debian developer, I don't use nor plan
> to use FreeBSD or NetBSD]
>
> For Debian to target for release a new port, the port has to match
> the release minima which are:
> 1) all base package
> 2) 90% of all packages build
> 3) a working installer
> 4) suitable machine to handle security updates.
>
> Before the port is targeted for release, Debian developers are not
> required to make any effort toward making their packages build on
> the port, even applying patches.
>
> Debian developers are mostly GNU/Linux users and are likely to use
> GNU specific features, and not ready to stop this usage for a port
> that have yet to happen.
>
> 90% of all packages represent curently 6840 (source) packages, but
> is likely to double every 2 years.
>
> So your best bet to get your port released is to provide an environment
> as similar as the GNU/Linux so that most packages will build out of
> the box. Using glibc and GNU tools is a big step in this direction.
>
> Coming with a distribution with less feature/efficiency than the original
> *BSD flavour is not a problem as long as said feature are not part of
> the release criteria.
>
> Alternatively, maybe you don't want to release as a Debian port, and you
> prefer with a well-working set of packages with custom patches. In this
> case you have much more leeway, but then I question whether this should
> be endorsed by Debian at all, though you are welcome to do it.
Alternatively to that, we can simply continue to submit patches that
make the code more robust, and have a very high adoption rate upstream,
since they almost invariably fix coding errors or problems that cause
portability to be lost.
Probably 80% of the packages I've touched that are *not* toolchain/core
packages in some fashion, or very intricate, work straight out of the
box. No changes whatsoever.
Granted, getting 'base' to 100% is a much more painful prospect, but
since GCC already has the work done, XFree86 has the work done barring
maintenence on new X releases (IE, make sure it still works), Perl has
worked since day 3 (at least for me)... really, a large part of the
nasty stuff is past.
Let me put it this way: if something *depends* on things provided by Glibc,
it is so non-portable that I would seriously question whether it is, in
fact, useful at all. The primary exemption that I can think of (psutils and
kin) are already on my list of "things to make sure we have replacements
for that are suitable" (since they are *very* tightly bound to the kernel,
on NetBSD, I'm strongly considering having a 'kernutils' package which is
generated along with kernel-image, kernel-source, etc).
That, or convince NetBSD to provide enough support at the libc level so
that the GNU process utilities can actually run linked against it, but
since that seems like a lot more work for marginal reward, I haven't really
investigated just how deep that would have to go.
Might be useful, if someone is looking for a short-term project, for
them to research that. (hint, hint :)
Of the release criteria, I would say:
1) I used to have a webpage up; something like 70% of base was working in a
reasonable fashion, if not all perfectly, and the rest looked like cleanup
and half a dozen major issues (where I define 'major' as requiring most of
my free cycles for a week or two to resolve meaningfully).
2) Is a matter of having a buildd (what some of my new hardware is intended
to serve as, at least for the time being and possbily in an ongoing
fashion), and spending the time to submit patches to fix what doesn't work.
As I said above, probably 80% of the non-massive packages I've dealt with
came out without significant problems. Which puts us well along the path
towards a 90% build rate, right there, just by having a buildd.
3) I've talked to the debian-installer folks about this, and we've hashed
over parts extensively. Right now, it's been less of a priority for me,
personally, because I run everything in a chroot from a native box, but
it will need to happen eventually. And will probably involve a few major
changes to d-i to support the BSDs, but probably only *one* set of them for
the entire set of BSD ports (whichever ones make it eventually to useful
levels of completeness).
4) This, I can't really speak to, except to say that I'm already donating
one machine (and network connection) to the cause, full-time, on my own
dime. Perhaps it's something we can use one of those ever-mentioned
spare i386 boxes for. Realistically, this is one of the *last* issues,
since a combination of 2 and 3 leads to the obvious result of "we can
install a machine, and we can run a buildd on a machine" - makes it fairly
straightforward to set up things and give them to the security team, once
we have the hardware.
And though you didn't mention it, in my mind at least, there's:
5) The 'look and feel' should not be jarringly different from any other
Debian box in the world (there is some room for argument, here, since a
Sparc box does actually have noticeable differences from an Intel box, and
either from an Alpha). That's part of why, at least IMO, the userland core
must be the GNU utilities that Debian uses for Linux - good or bad (and I
won't get into that), if 'ls' doesn't work like 'ls' on every other Debian
box, we've missed a large part of what makes Debian so useful to people.
Realistically, we might be able to target Sarge+1, if it's really a
year after Sarge and Sarge releases in, say, a couple of months - *if*
everything goes nearly perfectly. Since that seems pretty unlikely, I'd
say Sarge+2 is the earliest realistic timeframe, and by that time we're so
far out that making any sort of meaningful estimate is somewhere between
difficult and implausible.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpQMZ4aBLxha.pgp
Description: PGP signature