[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

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

Reply to: