Re: Backports vs Pinning Lenny
Hi Greg,
Greg Whiteley <whitty@smartchat.net.au> wrote:
Apologies for wading in :-p
Appreciation for you wading in!
I can see both sides [...and apparently quite clearly!]
There's probably two main stereotypes for BPO users:
1. The "SysAdmin". The SysAdmin wants to run Debian stable, because
it is stable. Inevitably practicalities dictate that some more-modern
versions of a few tools are needed because some damned development
feature just needs the latest version of java/apache/python/whatever.
That would be *almost* me. Although not technically a sysadmin (I'm a
web developer). I chose Debian because of its package management. And
I use backports (typically less than 5 or 6) only when "stable" loses
it's "B" (hence becoming "stale") enough that even non-bleeding-edge
things I need (typically recent *stable* versions of perl, apache or
MySQL... or any of the other letters in LAMP besides "L" :-)) are too
new to be found in the current Debian stable.
The SysAdmin installs < 20 packages from BPO, most are servers or
services.
For me, typically less than 10!
...SysAdmin probably uses pinning, and begrudges any package
being updated that is not exactly necessary.
No and yes. I don't pin (er, don't know how, and am not sure why), but
I *am* slightly annoyed by too-frequent updates... I just need the major
releases, and only after they are out long enough to be generally
considered "stable" by their user communities. And of course, those
pesky security fixes!
For example, while running Woody, I really, really needed perl 5.8 (it
wasn't available from bpo though so I had to install a "parallel
perl" -- google
"perlmonks debian parallel perl" for the gruesome details) and Myself 4
to get my work done.
When Sarge came out I needed (...and I got!) a clean upgrade path from
woody+bpo to pure sarge and I was All Good. For a while. Then at some
point I needed Apache2 and MySQL 4.1 (or was it 5? I forget) which
brought me back to backports to a sarge+bpo system that worked just
great. I think bpo got me to Samba 3 during that period also.
The upgrade to pure etch from sarge+bpo was a little trickier, but not
too bad.
I admit that a lot of this discussion is over my head, but I keep
reading... because it sounds like changes may be afoot, and I'd just
like to chime in with my use-case:
LazyWebDev:
Runs pure stable until client/market needs dictate that I upgrade to
some major recent (and considered stable) release of something in order
to support, or develop against, it (Apache, MySQL, Perl, sometimes even
a newer mail system, LDAP or Samba server release) that came out *after*
stable shipped and for which no debian package will be forthcoming until
the next "testing" becomes "stable".
So I need bpo to be my stable-but-not-stale solution. To be honest, if
debian could get the stable release cycle under, say, a year I might not
need backports at all. Until then, backports provides me with debian
stable-not-stale.
And I'm a little surly, too :-) and lazy...
...SysAdmin is a little
surly ;) SysAdmin is planning a timeline to move to etch some time
in 2007. Some time later etch won't be enough for some service and
SysAdmin will start adding etch-backports.
mee 2
2. The "LAG". The "LAG" wants the "Latest-And-Greatest" applications
...probably a desktop user.
Just in case its not obvious, LAG is soooooo... not me! I don't run X,
my Debian systems are internet-facing web application (plus mail, ftp,
dns & so forth) servers and the development servers that mimic them.
The least-cost path I would suggest is:
1. "Freeze" sarge-backports such that packages are updated only up to
the level of "etch + security", not only does this reduce developer
support-load, but makes the transition to etch simpler for SysAdmin.
Yes. Mee too that, too. If I had not already upgraded to etch by now,
I'd want my sarge+bpo boxen, typically the critical ones that are
working well and so I'm in no hurry to upgrade, to become, you know:
uber-stable :-)
Thanks,
-dave
Reply to: