2008/8/28 Tim Edwards <[EMAIL PROTECTED]>

> The way Debian does it this is [...] release a new distro version every X
> months, in Debian-speak these are called 'stable' releases, and then provide
> *backported* security and bug fix updates for however long that version is
> in support. These fixes are backported into the version of each package that
> was released with the distro to ensure stability - as no new features are
> being added the behaviour of the packaged software shouldn't change. But you
> still get the benefit of security and bug fixes so you get both a stable
> system (as in the behaviour of the software on it is consistent) and a
> secure one (up-to-date on all security patches).

Okay, so if I understand you correctly, a backport is a kind of refactoring:
the overt functionality doesn't change, but the underlying functionality
does (the refactored code is more secure, or less memory intensive, or
what-have-you depending on the nature of the fix). I hadn't previously quite
been sure that backports really are intended to *not change the overt
functionality*.

The tradeoff of course is that you don't get the latest versions of every
> package that's just been released. It's alright to think about upgrading one
> package to the latest version but when you have 20,000 or so, all constantly
> changing and on the bleeding-edge version you wouldn't have a very usable
> distro.

Agreed, for the most part. With security packages, I'm less certain. I guess
this is because with security packages, there's a grey area in which what
constitutes a security fix (and therefore will be backported) and what
constitutes a new feature, is disputable. My impression is that perhaps not
everything


> It looks like your environment requires you to use new features in the
> latest version of this package so you should just use that package from
> lenny - mixing one or 2 packages from lenny isn't going to cause any harm.
>
This is an interesting suggestion, given that near the start of this thread,
one of Debian's rkhunter package maintainers recommended against this
approach, and advised using his unofficial rkhunter backport instead.

So now I'm confused: which is the better approach for me to take? Also, why
would a maintainer be maintaining unofficial backports instead of (or as
well as) official ones?

With thanks in advance for your advice!

Sam

Reply via email to