Problem Report Number | 0014 (INT.0003) |
---|---|
Submitter's Classification | Specification Problem (INT) |
State | Resolved |
Resolution | Interpretation (INT) |
Raised | 2002-08-16 16:42 |
Updated | 2002-09-05 08:28 |
Published | 2002-09-05 08:28 |
Certification Program | Linux Standard Base Conformance Release 1.2 |
Test Suite | lsb-runtime IA32 version 1.2.1-1 |
Test Identification | LSB.os/procenv/nice/T.nice 5-8 |
Specification | Linux Standard Base Specification 1.2 |
Location in Spec | A-16 |
Problem Summary | Requirements for nice@GLIBC_2.2 break binary compatability |
Problem Text | Sorry about this :( The SUS spec for nice@GLIBC_2.2, as tested in the LSB test suite, are different to what was nice@GLIBC_2.2 in glibc up until recently (March 2, 2002 in glibc CVS). Unfortunately the change in return codes make a number of applications misinterpret the result of a nice() call as having failed, most notably start-stop-daemon for Debian systems. A brief review of the apps that use nice on my system comes up with: atd ignores the return value. procmail expects it to be SUS-ish, and doesn't raise it's priority properly if not. python checks for it at compile time, and uses getpriority() to emulate SUS-style if it found a Linux-style nice(). grip ignores the return value. samuel/saml treats non-zero returns as errors. xscreensaver-gnome assumes SUS-like behaviour, and won't behave quite as expected if it's initially running at a nice level != 0. Although, actually the code for that's broken too. zsh ignores the return value. scm expects Linux-style nice and looks like it exports that expectation to Scheme scripts that use nice. procinfo ignores the return value. For comparison, programs that expect nice to behave as SUS specifies generally cope reasonably gracefully with the Linux breakage -- they don't error out unnecessarily, they either treat is as a success, at worst not managing to get quite the nice level they wanted. Unfortunately programs that expect Linux-style returns from nice and get SUS-style returns tend to fail outright. More unfortunately, making this change in a point release of the Debian "stable" distribution doesn't seem plausible to either myself (as release manager), or Martin Schulze (as stable release manager) -- it has the potential to break too much software, and that's something we just don't do (deliberately, anyway) in stable. So, what we'd like is to have this portion of the test battery waived, on account of any of: * spec should transition to using nice@GLIBC_2.2.6, leaving nice@GLIBC_2.2 for backwards compatability. * current spec should allow either Linux or SUS style nice behaviour, with Linux style deprecated, and made illegal with LSB 2.0 or so. * spec should stay as it is, but Debian should be let get away with this ever-so minor infraction because we're all such nice people at heart, and it probably won't affect any ISV's anyway. Once again, sorry about doing this :( |
Test Output | - |
Review Type | SA Review |
---|---|
Start Date | 2002-08-16 16:42 |
Last Updated | 2002-09-04 11:14 |
Completed | 2002-09-04 11:14 |
Status | Complete |
Review Resolution | Interpretation (INT) |
Review Conclusion | Spec has been modified to allow either SUS or GNU behavior. Applications are advised to check return code and errno carefully to determine the result. |
Copyright 2005, The Free Standards Group, All Rights Reserved