On Thu,28.Aug.08, 22:27:04, Sam Kuper wrote: [...] > 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*. Say package foo has a security issue and upstream is at 1.4 and Debian still has 1.3. Upstream will most likely release 1.4.1 to fix the issue (which could be just a few lines of code) and maybe some others small bugfixes that were pending. Debian instead will look for the exact change for the security fix and apply it to the 1.3 version. In most cases it will not even need adaptation for 1.3 so they can just apply the specific patch. However, they will ignore whatever *other* changes have happened between 1.3 and 1.4 and also between 1.4 and 1.4.1. Unstable will of course get 1.4.1 ASAP. > > 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? volatile is suited for packages that change *often* and will become unusable unless you upgrade. A good example is an antivirus software and its definition files. Even if you upgrade the definitions you also have to upgrade the software itself in order for it to detect new viruses. I'm not sure rkhunter qualifies for volatile, but you should be able to find the requirements somewhere on the 'net. Making backports.org an official Debian service would solve issues like this, but I guess manpower is lacking... Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein)
Attachment:
signature.asc
Description: Digital signature