Re: Branding as separate distro vs. add-on to Debian
On Fri, 10 Jun 2011, Jeremiah Foster wrote:
On Jun 10, 2011, at 08:38, Andreas Tille wrote:
On Thu, Jun 09, 2011 at 12:37:04PM -0400, Geoffrey Thomas wrote:
I work on Debathena, which packages MIT's Project Athena clients
Any reason not to build these as official Debian / Ubuntu packages?
When I was working at MIT there was a project called SIPB Debian. Sam
Hartman worked a lot on it back in 2002 or so. They created a copy of
MIT's Athena environment or rather integrated Athena into SIPB Debian.
Is Debathena built on that work? if so, perhaps using regular "official"
Debian packages and packaging process might be a good approach as I know
this was the approach taken with SIPB Debian.
We are certainly using proper Debian packaging, following policy and
staying as close to lintian-clean as possible for an organization that's
not Debian, using sbuild for build infrastructure, etc. (This work is
based on SIPB Debian but I don't think it shares code, but Sam and other
DDs in SIPB have been involved in various ways.)
There are a couple of reasons this can't be upstream:
* We need to release updates on a much faster schedule (days to weeks)
than even the best Debian or Ubuntu release process, and we need to be
able to releae updates for stable distros. Unlike upstream, unless we
update a package in a way that FTBFS on older releases (which we actively
avoid), we pass a package off to sbuild for every supported release and
add a ~debianX.Y version tag (for upgrades). I imagine if we upstreamed
this, turnaround time for Debian unstable would be a few weeks and Ubuntu
unstable a few more, and SRUs would be close to impossible.
* We patch packages from upstream sometimes. This has become rarer with
time, but we still need to apply fixes that are high-priority in our
enviromnent, such as compiling with Kerberos support, checking the return
value of close(), etc. regardless of whether the packager or upstream is
busy.
* Many of these packages are MIT-specific. I don't see why Debian or
Ubuntu wants a set of bashrc.d and tcshrc.d files that figure out if
you're on MIT's Exchange or Cyrus servers and reports your mail quota as
appropriate, etc. (We can certainly upstream clients without config,
although we're basically the only site that uses Discuss and Moira and
Lert and such as far as I know, and I'd encourage sites that want to use
them to look at more common alternatives; we simply have a historic
investment in those apps. Several Project Athena clients that are wanted
outside have already been upstreamed, e.g., Hesiod, Zephyr, athena-jot,
not to mention e.g. Kerberos...)
* Many are not appropriate for Debian at all. debathena-kerberos-config
sets your default realm to ATHENA.MIT.EDU and turns on allow_weak_crypto
(historical reasons again, don't ask, this is being worked on).
debathena-network-manager-config automatically joins the "MIT" wifi
network before the login screen so network logins work, etc. As you leave
the laptop realm and go to the public workstation realm, we have packages
that manage automatic remote upgrades based on our schedule, etc.
I don't think any of this is specific to our environment. Many of the
places I've worked have corporate apt repos that configure you to get on
the LAN and to other corporate resources. CSAIL, at MIT, has CSAIL Debian,
which probably has more DDs maintaining it than we do. Boston University
across the river has BU Linux, an RHEL fork. And I imagine all these are
true for the derivatives on this mailing list.
I'm certainly a fan of upstreaming work -- we've been dropping custom
configuration and code for equivalents frmom upstream, and working on
sending back improvements. (Until 2007, you did in fact have to install
Athena as its own OS; it was based on RHEL or Solaris, but had such things
as its own display manager.) But I don't think upstreaming the entire
project makes sense.
as well
as configuration for network logins, integration with MIT's
authentication infrastructure, etc.
... and do the configuration using proper debconf usage?
Sometimes we can configure things using debconf. Often not.
* Debconf is a cache, not a database. We want to enforce the configuration
stays, and don't want the user to be prompted to remember what MIT's mail
server or LDAP server or Kerberos realm or such is at package upgrade
time.
* Similarly, we want the configuration undone cleanly when you uninstall
the package.
* Many times we can just drop in a file in a .d directory.
* For the cases where we need to modify configuration files, we use
config-package-dev to cleanly dpkg-divert them:
http://debathena.mit.edu/config-packages
http://wiki.debian.org/ConfigPackages
I really don't think a package that dpkg-diverts /etc/krb5.conf and
replaces it with MIT's makes sense in Debian, although it's a very clean
solution for us and integrates safely with the packaging system, and is
one of the most basic packages you need to get Debathena working.
Anyway, in short, I'm happy to upstreamworks, but this list exists
because there are cases where derivatives are appropriate. (Take Ubuntu
for example.) But as a derivative we have a different branding approach
for our individual users: your laptop runs Debian or Ubuntu with
Debathena, not Debathena on its own. I'm curious to hear from other
derivatives that take that approach.
--
Geoffrey Thomas
geofft@mit.edu
Reply to: