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

Re: [mailinglists] Re: Trusting Backports and unofficial Repositories



On Tue, Jul 20, 2004 at 09:41:54AM +0200, Philipp wrote:
> first, thank you for you long and comprehensive answer, but we wont use
> unstable.

they're your servers, so your choice.  i wasn't telling you what you should do,
i was informing you that there was another very viable alternative and that no
matter how scary the label "unstable" sounds, running sid on production servers
isn't a danger for people who know what they are doing.

'unstable' and 'stable' does NOT refer to the likelihood of the software
failing or crashing.  it refers ONLY to the fact of whether the software
changes/is upgraded.  software in 'stable' never changes (except for a handful
of rare and very important security updates).  software in 'unstable' changes
regularly, sometimes even several times in a given day.


> my workstation is "testing", and i upgrade every week. 

then you have the worst of both stable and unstable, compounded by long
stretches when packages are broken because it takes weeks for fixed packages to
trickle into 'testing' from 'unstable'.  testing is ONLY useful for testing the
next release of debian as it develops.  it is NOT a safe middle-ground between
stable and unstable.  it is a huge mistake to think of 'testing' in that way.

if your experience with testing scares you off unstable because you think it
must be worse, then you are quite mistaken.  unstable is far less trouble and
far more pleasant to work with (not to mention more up-to-date) than testing.

> 2) unstable is, as the debian developers put it, unstable. 

some do.  most don't.  in fact, most debian developers run unstable on most or
all of their machines.  i'm a debian developer and i run it on all of my
machines.

the only use i have for stable is the convenience of the install CD to install
the base system, which then immediately gets upgraded to the latest unstable
from my mirror.

testing i have no use at all for, but i do generally try it out around the time
that the next release is being prepared so that i can contribute to the frenzy
of bug-squashing. 


BTW, everyone i know who runs unstable (which is the majority of debian users
and developers that i know) runs it for pretty much the same reasons as i do,
and with similar lack of problems.
 
> the major point is, that you cannnot chose to have a stable packages of, lets
> say, gd, but an unstable php. 

so, you run unstable gd and php.  it works.

> if you install the unstable php with gd support it will ask for the depended
> gd-version.  so many packages will be unstable.

yes.  but at least you know that they have been well-tested together and that
they have been compiled together with the same version of the compiler and same
version of libraries, and that the debian infrastucture is there to support
them.  the same is NOT true of unofficial backport packages.


> > i really don't see the point of stable+backports - installing backports
> > defeats the original purpose of running stable, it's like saying "i'll have
> > a black coffee......but with a little bit of cream"*, so you may as well
> > run unstable.
> 
> i dont think so. the purpose of debian stable is running a stable system and
> you still do to a certain point if you run a few backported packages.  [...]
> 
> its the same with backports in my opinion: using a stable system has the
> advantage to be stable. but for a few packages you are in the need for
> features. 

but now it's no longer 'stable', so you've defeated the purpose of staying with
stable.

that's fine and it may work well for you, but telling yourself that it is still
'stable' (or even that it is any more stable or reliable than 'unstable') is
pure self-delusion.  what you have is an untested and unique hybrid, that is
quite different (possibly in subtle bug-inducing ways) from ANYONE else's
system.  you're the sole guinea-pig for your combination of packages and
versions, so your ability to benefit from other people's experiences and
reports is reduced.


> whats better now: putting some cream in the coffee or go for pure milk ?

i prefer full cream, no sugar :)


in the end, though, they're your servers so you run what you want on them.
none of my business at all.  i'm just trying to correct your mistaken
impression of the differences between stable, testing, and unstable.  you still
make your choices however you like (and choosing to run stable, with or without
backports, is still a valid and perfectly reasonable choice) but it is better
to choose with full knowledge of the alternatives than to decide based on a
mistake.
 
craig

ps: another point about "unstable" - nothing is ever forcing you to upgrade
when you don't want to.  if your latest unstable upgrade has all your packages
working exactly as you want and there are no bugs or security holes discovered
that bother you and there's no new features that you need or want, then don't
upgrade until you need to.  in short, "if it's working, don't fix it".

also, you don't have to do a full upgrade to unstable.  you can upgrade just
what you need and only the packages you specify plus any required versions of
dependancies will be upgraded (usually the exact same dependancies that would
be required by any backports upgrade, except that they're official debian
packages rather than unofficial and unsupported).  the rest will stay as they
were.

so, who needs backports when debian's package management tools and ftp archive
already caters for that need, and has done so nearly from the start? 



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

The next time you vote, remember that "Regime change begins at home"



Reply to: