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

Re: rkhunter on Etch





2008/8/28 Tim Edwards <timothy.edwards.ext@siemens.com>
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 to: