[conspire] Sat, 1/10 Installfest/RSVP

[Rick Moen]

Quoting Nick Moffitt (nick at zork.net):

> Because it saves me the work of recompiling or upgrading software that
> is running a production service. 

All my software that runs production services upgrades just fine.
However, you haven't answered the question:   Why do you, specifically
-you-, need a consistent application _binary_ interface?  Do you install
a significant amount of fragile software that's available only in binary
form?

All the software I install is maintained and available in source form,
meaning that I don't need to keep the binary interface to my libs and
system calls rigidly fixed for some binary-only application's benefit,
but can keep doing a continual rolling upgrade.

> Yeah, I used to think this way too.  I just spent too much time in the
> #debian channels on IRC when the topic was set to "STOP NOBODY
> DIST-UPGRADE ZOMFG".  I managed to bork my own systems too many times on
> unstable. And then testing really didn't live up to my expectations.  

I didn't say "on unstable".  I said testing/unstable.

:r! /etc/apt/preferences

Package: *
Pin: release a=unstable
Pin-Priority: 50

I fetch testing-branch packages except where I qualify my command with
option "-t unstable".  Thus, no unstable-branch breakage because the
glibc maintainer got roaring drunk and was sobering up only around 4 PM
Monday -- but I also have optional access to unstable-branch packages
and their dependencies when/if needed.

> Those desktops are all a pretty singular role.  Having hundreds of
> servers on various hardware types and different networks with vastly
> different roles is a completely different scenario.  I maintain that the
> system at VA worked only because it was a desktop system that did not
> have the uptime requirements of a production server.

Well, my server experience suggests that I get the same results as the
VA setup did, and without even the safeguard of a golden master machine
on which to test before deplyment.

> Consider, just for an example, the horror that is the Mailman package in
> Debian/Ubuntu:  It forces you to throw away all mail currently in-queue
> during an upgrade even if it's a -* release (identical upstream source,
> maintainer-applied changes).  It basically punishes you for actually
> *using* Mailman.

I never assumed that the in-queue mail would be stable between releases,
(or major ones, anyway) and always flush the queue.  This has thus never
been a problem.

> So if you're upgrading mailman to every new package that appears, that's
> a regular nightmare of shutting down MTAs, flushing queues, deleting
> apparent spam with prejudice, etc.  That's simply unacceptable for a
> production mailing list server with zillions of messages flowing
> through.  

I've been upgrading Mailman and sendmail/exim3/exim4 on Debian for ages,
and somehow have never lost mail.