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

Re: When Debian 4.1 will arrive... will anyone care?



On Fri, Apr 20, 2007 at 12:21:39PM +0200, Frank Küster wrote:
> Craig Sanders <cas@taz.net.au> wrote:
> 
> > On Fri, Apr 20, 2007 at 09:27:48PM +1200, Nick Phillips wrote:
> >> Craig Sanders wrote:
> >> > IMO, if you need a 'stable' system with some newer packages, you're
> >> > better off learning how apt's pinning stuff works than bothering with
> >> > backports.  it's not hard.
> >> 
> >> The big difference is that with backports, they will be built with
> >> stable libs etc. as far as possible -- that means a hell of a lot less
> >> gets pulled in than with testing/unstable, no matter how you pin.
> >
> > 1. why is this allegedly a 'benefit'? what's so special about libraries?
> > why is a new libc6 or libssl etc more scary than a new apache or php
> > etc?
> 
> - because it's much harder to go back

are you talking theory or practice here? because IN PRACTICE, it isn't.
i've upgraded and downgraded packages at will with no particular
difficulty. even libc6 on occasion.

> - because if there's a bug, or an unknown incompatibility, it's not just
>   apache which breaks, but the whole system (in case of glibc, or other
>   central libraries)

and the same is true of packages in backports. a serious bug can break
your system (or, at least, require significant effort to get it back to
a known good state). in my experience, using unstable for over 10 years,
i see no reason to even suspect, let alone believe, that unstable is any
more likely to have serious bugs of that nature than backports is.

but if you want to delude yourself that backports is magically safer
than testing or unstable then go right ahead. there's no law against
being mistaken.


AND, as i said before, anyone with any sense whatsoever will test
*ALL* upgrades, even the most trivial, on another machine first BEFORE
applying it to their production servers. anyone who doesn't do that
should be blaming themselves before they blame either unstable or
testing or backports.


> - simply reducing the number of packages from non-stable makes it easier
>   to maintain your overview of what's going on on your system.

only if you start off with the bogus premise that there's something
wrong with unstable.....which makes me wonder, if 'unstable' is so bad,
then why are you so keen on re-inventing it in another guise (because
that's all backports is - another version of unstable).



> > 2. backports has new/updated libraries too. it may not be the exact same
> > set of updated libs as in unstable, 
> 
> Sorry, did you ever care to read the backports.org policy?  Or even try
> to use them, or work with people who do?
> 
> I guess no, since of course "it may not" is plain wrong: backports.org
> only has packages from testing.

english obviously isn't your native tongue. "it may not" is, in context,
a softer way of saying "is not" with the added implication that whether
it is or isn't is basically irrelevant.

if you're going to attempt lame grammar flames, then at least do so only
in languages in which you are proficient.

especially if you're going to try a hang a conclusion on it.

> > in my experience, backports causes more trouble than either testing
> > or unstable. for one thing, you're running non-standard stuff
> > that doesn't get tested anywhere near as much as the stuff in
> > testing/unstable. and, more importantly, the upgrade path from
> > backports to the next stable release isn't tested anywhere near as
> > much as the upgrade path from old-stable to new-stable, or from
> > testing/unstable to newer testing/unstable (or to new stable)....so
> > you're going to have new and exciting problems when the next stable
> > release comes around.
>
> As far as the TeX packages are concerned, I can tell you at least that
> one of the major TeX maintainers actually used the sarge-backports
> (me), and that we did get feedback from backports users, but no bug
> reports that wouldn't have also been in testing (and most bugs of the
> type "upgrade scenario not considered" happen to *unstable* users).

sometimes it happens, sometimes it doesn't. it may or may not happen.
that's besides the point. the point is, you can't count on it. tex may
have had the upgrade path tested. apache or php or whatever may not
have. the point is, that the upgrade path from backports is far less
tested than either 'testing' or 'unstable'.

craig

-- 
craig sanders <cas@taz.net.au>

"Power tends to corrupt and absolute power corrupts absolutely.
 That unalterable rule applies both to God and man."
   [John Emerich Edward Dalberg-Acton (Lord Acton) in
    a letter to Bishop Mandell Creighton, April 5,1887]



Reply to: