[conspire] Sat, 1/10 Installfest/RSVP
rick at linuxmafia.com
Mon Jan 12 10:44:58 PST 2009
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
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.
Pin: release a=unstable
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
I've been upgrading Mailman and sendmail/exim3/exim4 on Debian for ages,
and somehow have never lost mail.
More information about the conspire