On Tue, Nov 29, 2005 at 10:54:41PM -0500, Chris Lawrence wrote: > I am confused as to why you have rated this bug as "important." As > you point out, there is no real way to make this determination in > software without breaking the automated sid->etch migration process; > the best that can be hoped for is an educated guess based on > apt-policy, but even that could be wrong (for example, someone who > prefers testing to unstable but has a crapload of unstable installed > anyway).
Well, the lsb-release script is supposed to give you a proper relase codename and it fails to do that at all for etch. I believe that is an important bug, since the script is useless in etch. People (or scripts) might want to depend on its functionality to do stuff and might (wrongly) believe that 'lsb_release -c' would return 'etch' when it does not. > It's something of a known deficiency, and I have no easy solution... > nor do I think it's all that important to fix. YMMV, of course. It's important since for all the testing release process 'lsb_release -c' is useless and nobody can depend on it. There is no easy solution, but providing a script that fails to do what it's supposed to do is not the best course of action. IMHO this unexpected behaviour should be documented properly, worked around (a different lsb-release package in etch than in sid could be possible), or try to bug others to find a different solution to this problem. Shrugging it off helps nobody and I know people that expect this to work for some things (like checking security bugs and available packages based on release and package versions) Regards Javier
signature.asc
Description: Digital signature
