[863] in NetBSD-Development
Release system goals
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jul 7 02:25:10 1995
Date: Fri, 7 Jul 1995 02:26:47 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: netbsd-dev@MIT.EDU
So, various people have had ideas about a versioning system/release
cycle for the Athena port. I'd like to clarify things by pointing out
specifically the problems we want to solve:
1. We want to distribute bugfixes and improvements to the
operating system as well as to /bin/athena and /etc/athena,
but we don't necessarily want to override people's local
customizations or destabilize their base system.
2. We want to be able to make modifications on the packs
(/usr/athena) which depend on bugfixes or improvements in
the local filesystem. For instance, it's more or less luck
alone that we didn't have a problem moving /usr/bin/login
to /bin/athena/login (since /etc/athena/telnetd and
/etc/gettytab are both on the local filesystem). An
obvious example of this is having xlogin set the user's pag,
which depends on AFS handling setgroups() properly.
3. We need to take into account that some users (especially in
Pika or across the river) want some or all of /usr/athena,
/usr/X11R6, /usr/andrew, and /emul/linux local.
4. We want to avoid munching lots of disk space with copies,
or having big symlink farms.
Yoav has suggested having an /etc/athena/version and a
/usr/athena/etc/version, and performing an automatic update if they
don't match. But this doesn't really solve problem 2, since we can't
guarantee that automatic updates will happen before things break, and
we wouldn't want to make updates mandatory (since that would be
invading people's systems too much for my taste).
The Athena approach would have us make a copy of the system packs for
each release cycle. Incompatible changes on the packs are only made
during numbered releases (e.g. 7.6 to 7.7), and the system is (or
should be) guaranteed to be updated before the machine starts
referring to the new system packs. Lettered releases modify the
system packs in place, and machines should update to get bugfixes and
improvements on the root filesystem, but incompatibilities between
packs and the local filesystems shouldn't be introduced.
The Athena approach solves problems 1 and 2, but at the expense of
forcing us to make lots of copies or symlink farms, neither of which
I'm happy about. AFS union mounts could make things cleaner (you
would have a complete set of files in the first release union mounted
under the local filesystem at /srvd, and then you would add successive
union mounts between the first release and the top level for each
release). On the other hand, I don't think AFS union mounts work yet
and I'm wary of confusing both users and maintainers by taking
advantage of too much filesystem magic. Union mounts would, however,
make it trivial for users to store files locally or make local
modifications to things on the packs, something I've wanted for a long
time.
jhawk suggested making releases modular, but wasn't entirely clear on
what that meant, and at this point I discern more complications than
advantages in trying to pay attention to such a criterion.
Finally, there's the Linux-Athena approach, which is to have everyone
put everything local on their system. I'm not keen on sacrificing the
low space requirements of the NetBSD-Athena port, and that approach
certainly doesn't solve problem 1 at all.
