2008/8/29 Andrei Popescu <[EMAIL PROTECTED]> > 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. > > 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... > Thanks for the comments, Andrei. I feel I'm starting to understand much better how Debian packages are maintained, and when I should consider backports or non-"stable" packages (i.e. only as a last resort, if the needed functionality isn't available in stable).
Sam