Re: backports.org became really shitty for php5-mysql and mysql-server-5.0
On Sat, Mar 17, 2007 at 06:20:52PM -0400, Roberto C. Sanchez wrote:
> On Sun, Mar 18, 2007 at 08:11:15AM +1100, Craig Sanders wrote:
> >
> > well, what did you expect?
> >
> > if you're using backports.org, you may as well be using unstable.
> >
> That's not quite true. You may as well be using unstable for the
> packages you are pulling from backports.
yes, it's not quite true. it's not as good as using 'unstable.
but in terms of what it does to the 'pristine' status of an allegedly
'stable' system, it's effectively the same. if you're using backports,
then you're no longer running 'stable' and it's just plain stupid to
fool yourself that you are.
> > in fact, you're better off with unstable because there are more people
> > using it, so it is better tested. with backports.org, you can be pretty
> > sure that NOBODY else is using your exact combination of libraries and
> > other packages....so you may be the ONLY person to ever encounter a
> > particular bug.
>
> Really? So, he's better off with unstable so that he can potentially be
> the first user to find it there instead of in backports? So that he can
> also be potentially bitten by any number of bugs which invariably hit
> unstable first?
yes. MUCH better off.
i've been running unstable on hundreds of servers and desktops for over 10
years.
i don't even need a whole hand of fingers to count the serious problems
caused by packages in unstable in that time.
only once has a problem occured that took me more than an hour minutes
to fix. and only a few times has a problem occurred that took me more
than 10-15 minutes to fix. most "problems" are trivial - changes in
config file format between one version of a program and the next.
OTOH, i've upgraded numerous servers from one version of 'stable' to
the next version of 'stable' over the years. that is *ALWAYS* a massive
PITA because it has generally been at least a year or two between stable
releases...and even with all the testing done before a release, some
things don't go anywhere near as smoothly as they should.
IMO, it's better to upgrade a couple of dozen packages every few weeks
than a few thousand packages every few years. less to go wrong at any
one time.
> > IMO, backports.org is just a second-rate way of running 'unstable' for
> > people who are scared by the name 'unstable'.
that needs saying again.
'unstable' isn't anywhere near as scary as the name implies.
if you NEED a stable (as in "unchanging") system then just stick with
'stable' and security-updates. don't fool yourself that stable+backports
is any better than 'unstable', because it isn't - and it's often worse.
otherwise, use 'testing' or 'unstable'. don't waste your time with
third-party stuff like backports.
> > (and 'testing' is a way of running 'unstable' with a long delay
> > for any urgent fixes. although at least it also serves the useful
> > purpose of testing the next release so it's a good thing that some
> > people use it)
>
> If an orphaned package is the subject of a security advisory, who
> fixes it? In stable, it is the security team. In unstable, there is
> no obligation for anybody to provide security support. Someone on the
big deal. in practice, security updates are in stable either at the same
time as in stable, or the package concerned was upgraded months before anyone
even discovered that there was a security hole in it.
keeping months or years ahead of the script kiddies is one of the reason i use
unstable.
> security team or the QA team may be nice enough to do a QA upload of
> the new version of the package (as many upstream developers release
> security fixes by releasing whole new versions), but nobody is
> obligated to do that.
read the fine print. nobody's *obligated* to do it for stable,
either. and certainly not for backports (which has inherent security
implications because backporters aren't vetted and don't have to be in
the web of trust like debian developers are - yes, many are DDs...not
all).
like everything in debian, security updates are done on a "best-effort"
basis. the fact that debian's "best-effort" tends to be miles ahead of
any commercial, paid-for "guarantee" doesn't change the fact that it's a
best-effort.
craig
--
craig sanders <cas@taz.net.au>
BOFH excuse #261:
The Usenet news is out of date
Reply to: