[1962] in NetBSD-Development
Re: Athena packages suitable for pkgsrc
daemon@ATHENA.MIT.EDU (Nathan J. Williams)
Fri Jun 23 15:15:05 2000
To: Richard Tibbetts <tibbetts@MIT.EDU>
Cc: matt <deberg@MIT.EDU>, netbsd-dev@MIT.EDU, tibbetts@MIT.EDU
From: nathanw@MIT.EDU (Nathan J. Williams)
Date: 23 Jun 2000 15:09:55 -0400
In-Reply-To: Richard Tibbetts's message of "Fri, 23 Jun 2000 13:43:43 -0400"
Richard Tibbetts <tibbetts@MIT.EDU> writes:
> > what is the "plight" of netbsd-athena? we've been lame about getting a
> > release out, and at this point i wonder if it's not worth just skipping
> > 8.3 and doing 8.4, but i don't think it's ever been a goal to "beat out"
> > either SIPB or I/S linux-athena. regardless of the state of any
> > linux-athena port, i want to be using netbsd.
The "plight" is that we (and by "we" I mostly mean "I", since I didn't
think anyone else was working on the x86 side of things) have been
exceptionally lame, to the point that:
- Our users have an OS version that is more than a full
release behind.
- Our users have an Athena version that is one full release
and will shortly be two full releases behind.
- Our mechanics have not kept pace with the changing trend of
Athena to be more package-oriented.
At this point I view NetBSD-Athena as a fringe product with
essentially no value. The small and shrinking number of people who
want to run it are all quite able to build the packages
themselves. NetBSD/i386 Athena binaries are about as valuable as SunOS
4, HP-UX, or Apollo Athena binaries.
> Ok, that probably qualifies as the most impolitic mail I have sent
> this month (and I am a pretty tactless person). s/plight/status/. Two
> years ago when I got here NetBSD-Athena was the correct solution for
> clueless people (clueless == people who can't tell the difference
> between Linux and NetBSD) who wanted to run Athena on their Intel
> machine. It is possible that this just happened, rather than being a
> goal of the developers.
This was a goal we inherited by cloning the mainline Athena
maintenance process, and while it was certainly valuable (and better
than the Linux-based solutions of the time), it is almost certain that
it will be preferable for new students with PCs that they wish to
Athenize to use some version of I/S-Redhat Linux, from portability,
usability, and maintenance aspects.
Another way to look at this is that when I/S was not supporting Athena
on PC's, SIPB provided the service, and in fact provided it in a
couple of different ways that gave valuable insight when I/S decided
to pick up the ball. Now that I/S has picked this up, it is time for
SIPB to step out of the role unless we believe that we can provide
substantial added value. I do not believe that NetBSD-Athena can do
that; in fact, it has some significant deficiencies, such as the
not-getting-any-younger AFS port, and the reliance on both binary
emulation and ATHENA_SYS_COMPAT for running both popular commercial
software and I/S maintained locker software.
> > i believe netbsd-athena 8.3 for both i386 and sparc are close to being
> > ready to go, and now that i've finished my thesis i plan on putting in
> > the time this summer to make those happen. (or something 8.4 based, or
> > whatever.)
>
> What I was really trying to say was that we might get most or all of
> the benefit of NetBSD-Athena by only offering packages, rather than
> trying to auto-update machines and maintain our own installer. I was
> under the impression that the thing NetBSD-Athena-8.3 was blocking on
> was update scripts and a new installer.
8.3: essentially correct. We don't even need a terribly new installer
if we're comfortable with the install-all-at-once model.
> As far as coming up with source tarballs goes, the 8.4 build system
> has a method of generating SRPMs for Layered Athena (as well as binary
> packages) and I expect that I could hack that a bit to do most/all of
> the work of creating NetBSD packages.
This is much more interesting and potentially valuable to the (fringe)
community of NetBSD users, particularly on non-i386 platforms. It's
too bad that NetBSD's package tools are no good at updating things,
though.
- Nathan
