On Wed, Nov 30, 2005 at 09:20:36AM -0500, Chris Lawrence wrote: > > More importantly, there is no real heuristic for figuring out whether > or not a system is "testing" or "unstable." Even if > /etc/debian_version was modified in etch, that's no guarantee the > system is actually "etch" - and no guarantee of what day's etch (if > any) it was. It could be the etch from the day sarge/3.1 was frozen, > or etch from the day before etch was promoted to the release. Or it > could be a bastardized, half-upgraded hybrid of sid, etch, and sarge.
You could tell (from /etc/apt/sources.list) wether the system is upgrading from testing (etch currently) or unstable (always sid). lsb_release could cope with that and try to make an intelligent guess. Granted, people can make mixed arrangements but those are not supported, either you run stable, you run testing, or you run sid because you either install with the stable release disks, the testing disks and then upgrade from any of those to sid. Unfortunately, lsb_release is not able to tell apart: - a system installed through the d-i testing disks and pointing to 'testing' for updates - a system installed through either d-i stable or d-i testing and upgraded (full dist-upgrade) to sid, and updating from there Those two cases should be the majority of cases, and that's what testing was introduced for, to provide a bleeding-edge system free of RC bugs (although it's not always this way). Users mixing stuff are not using testing as they should, although they are free to do it, there is not need to provide support for those corner cases. > The best you can hope for is that the "codename" line might be changed > to read "etch/sid". Or have lsb_release try to figure out if it's in testing or sid based on where it is updating from (hint: check out /etc/apt/sources.list and try to cope with the standard configuration most people will end up with). > And, the only proper way to check whether you have an up-to-date > version of a package is to check against the latest packages files for > each relevant release, something that is well beyond the scope of > lsb_release. Relying on the system's idea of what distribution it is > running isn't going to help you figure out whether the bug is in > testing or unstable. Wrong. For security patches you have: - Sarge (stable) updates through security.debian.org (version A - Etch (Testing) updates through http://secure-testing-master.debian.net/ (version B), notice the fact that it is not in the regular release file - Sid (unstable) updates through the regular package procedure (version C) Typically, A < B < C, but the fact that your package version (say X) is less than C does not imply that you are exposed (in the X=B case). That is true now, even though most security fixes for etch go through Sid (so there's never a 'B' version of the package), but might be moreso if security fixes (during the fereeze) go through the new testing security infrastructure. So, here's why your logic is flawed. Say you are running package version X which is vulnerable: - if you are running testing, you should upgrade to B, if B exists. If it doesn't exist, and C is not yet in testing, you are vulnerable and can only patch through the (unsupported) method of mixing up releases (if you do this you are no longer running testing and might open up a can of worms bringing in new, unexpected -and not security releated-, bugs) - if you are running sid, you should upgrade to C, which might or might not upgrade a lot of other elements of the system. That logic can be expanded to other system recommendations (as to how to fix other RC bugs which are in testing but not in sid). Notice how the lack of a standard way to determine if you are running testing or sid breaks the logic and why lsb_release should made an effort to lie to the user and tell him he is running 'sid' when he is not. Regards Javier
signature.asc
Description: Digital signature
