Neverending Story Part 2: LSB and woody
I've read older mails on this issue and here's the outcome.[1]
LSB Compliance Requirements
Modified packages:
http://people.debian.org/~ajt/lsb/dists/woody/lsb/main/binary-i386/
alien, glibc, kernel, pax
http://hackers.progeny.com/~licquia/lsb/tjreport-woody.200311032211.txt
http://hackers.progeny.com/~licquia/lsb/apt/
http://hackers.progeny.com/~licquia/lsb/patches/woody/
bash, cpio, glib, grep, kernel, lsb, pax, sed
alien
ajt: The alien changes have been in testing and unstable for a
similar amount of time.
Matt: Yeah these are probably fine.
Jeff: Woody alien has several bugs in its handling of permissions
and scripts when converting RPMs, which make it impossible to
properly install the test suite RPM. This results in many test
failures. These bugs are fixed in alien 8.36, and the test
results I've been generating have been from the test RPM as
installed by alien 8.36 on woody. No rebuilding or other
modifications have been necessary to get the alien package as
currently available in sarge to install on woody.
There may be good reason to use alien 8.37 from unstable, as it
fixes a bug I've noticed in testing sarge. But the results I've
been generating have been with 8.36, so I think that can be used
as a minimum.
bash
Jeff: Bash 2.05a does not support the [[:hyphen:]] glob, which
causes one test to fail. Because the changes between 2.05a and
2.05b are too great, I felt that a custom patch to just add the
support was the best option. This is the only patch I have
written, although support for the glob does appear to be in 2.05b.
cpio
Jeff: This is a very large patch, but the actual change is minimal.
Nearly all of the patch amounts to changes in configure caused by
a single configure.in change to check for a single additional
header file.
The actual code in the patch only adds a call to setlocale() at
the beginning of main(); the configure changes are only necessary
to make sure that setlocale() is supported. If we were to make
our patch assume the presence of setlocale() and thus not require
the autoconf change, the patch could be made extremely small and
minor.
glibc
ajt: The glibc changes are in unstable and upstream CVS, and have
already been tested in released versions of Red Hat, SuSE and
probably other distributions.
Matt: Again there may need to be additional changes for the new test
suites.
Jeff: The patch was written by Anthony Towns, and is adapted from a
patch from SuSE. The patch has been around for quite a while, and
has been released as part of at least one production distribution
(SuSE). The largest portion of the patch involves a test case
added to the test suite.
The bugs fixed all relate to incorrect error handling. Most are
improper errno values, although one relates to an incorrect return
value.
grep
Jeff: This patch adds wide character support to grep.
It is a large patch. Most of the changes have been accepted
upstream; the ones that still haven't are available at
http://www.openi18n.org/subgroups/utildev/patch/grep-2.5.1-i18n-0.1.patch.gz.
Any LSB 1.3 certified distribution will have incorporated this
patch. As such, it should be well-tested. Additionally, it
passes the LSB tests. Finally, I have run the test suite in the
grep source; while it does not pass, the original source doesn't
pass either, and the results of the patched source are identical
to the results of the source currently in woody.
kernel
ajt: The kernel changes have been tested everywhere that runs
2.4.19.
Matt: Is the kernel going to be updated for the next woody point
release? Some of the tests only pass with 2.4.20+ IIRC
Jeff: Only the latest patch file is needed
(lsb-kernel-patch-2003-10-28). This kernel patch fixes LSB
compliance issues with 2.4.18 that are also fixed in later
kernels. I believe all issues are fixed in 2.4.19; they are
definitely fixed in 2.4.20.
Thus, we could release 2.4.19 kernels (or later) to woody in lieu
of this patch. There are several benefits to this approach,
especially considering that it would not trigger a kernel update
for those people who don't care about the LSB issues. I have
heard, however, some reluctance to release newer kernels into
woody, which prompted the creation of this patch.
pax
ajt: The pax changes are straightforward and have been tested in
both testing and unstable for a couple of months.
Jeff: This patch backports a fix from sarge's pax to woody. The bug
number is 139943. Again, this is a well-tested fix, having been
released in a number of distributions, and having been a part of
Debian sid for over a year.
Since pax is mostly used for compliance with POSIX/LSB anyway, not
having a compliant pax is tantamount to not having pax in the
distribution at all.
sed
Jeff: Large portions of this patch are the result of autoconf and
automake, where the real changes are actually quite small. In
addition, some of the code changes amount to whitespace changes,
and in one case a .orig file generated by patch was included in
the patch. If patch size is a concern here, please let me know; I
will be working on removing as many unnecessary changes as I can
today.
The patch has been integrated into sed as of 4.0.1. It has also
been integrated into several shipping distributions; any LSB 1.3
certified distribution will have needed either this patch or sed
4.0.1 to pass certification. It also passes the LSB test suite
and its own internal test suite (which is required for the package
to build at all). This should serve as evidence that the patch
has been well-tested.
Comments:
ajt: Also, the nice() issue -- which does have the potential to
break things -- is irrelevant: we don't need to make that change
for LSB compliance.
Matt Taggart: These are a year old so should probably be reviewed to
make sure they are still relevant or don't need additional
updating for LSB 1.3.(As you mention below)
The lsb package was also just updated for 1.3, which adds a couple
archs , a missing dependency on pax, and some other stuff.
The separate OpenI18N standard was merged into the LSB at 1.3 so
there are additional requirements that are being tested for
now. These are mostly requirements on the commands provided by the
LSB and _will_ require patches to fix. I haven't yet file bugs
against these packages but will ASAP. I know Red Hat and SuSE have
been adding these patches to their in development releases in the
last few weeks. I do not know if the patches have been accepted
upstream yet. There's a rumor that they affect performance.
So the older versions of the 1.3 test suite didn't test for the
OpenI18N stuff but newer versions do. If we don't want to deal
with these patches for a woody point release then we might be able
to run the older version of the test suite. However the clock is
ticking as that version will expire at some point now that the new
one is out. Details at
http://www.opengroup.org/lsb/cert/docs/testsuites.html
It [lsb package] doesn't need to be installed on the system by the
default install, the certification process will optionally install
it with instructions from the submitter on how to do so. I
recommend that the new version be available in woody but it
doesn't need to be installed by default.
We also need updates of the lsb, lsb-release, lsb-rpm packages.
These should be easy to backport but needs to be done.
Jeff Licquia: lsb-rpm is a sarge innovation. As I recall, it was
made necessary by changes in rpm that happened after woody
released. Would the rpm from woody, therefore, be sufficient?
lsb depends on python 2.3. Is there any reason why python 2.2
wouldn't work?
Problems:
. kernel changes need to be applied to all kernels in woody,
especially to those distributed in woody not to those not
distributed in woody.
. If a different upstream kernel version is required than there is
currently in woody, for any architecture, this poses a threat and
cannot be fulfilled. In such a case we need to announce
people.debian..org/~ajt/lsb/ as additional resource if people want
to run an LSB certified system.
. http://hackers.progeny.com/~licquia/lsb/tjreport-woody.200311032211.txt
assumes that only one test really failed.
My proposal: Packages may go into woody all together or not at all,
they won't go in partially. All patches need to be present in the
sid version as well.
alien: Ok, unstable ok
bash: Ok, unstable ok
cpio: Ok, unstable ??
glibc: Ok, unstable ok
grep: Nah, this patch is way too long. Is this the only patch
required for Li18n or is it not required for Li18n tests but
only LSB 1.3? This also breaks translations of grep
partially, if existing. unstable ??
kernel: Ok, but would have to be applied to all kernels *sigh*,
unstable ok due to v>=2.4.20
pax: Ok, unstable ok
sed: Not ok, need a cleaner patch to review, unstable ok
Also: sed and grep mention openi18n in the changelog. Are these
the only changes required to pass the Openi18n tests? Are these
changes not required for the normal LSB 1.3 test suite?
Open questions:
1. Are grep and sed required for LSB 1.3?
2. Are grep and sed required for Openi18n?
3. Are there no more packages that need to be fixed for Openi18n?
4. Need a fix for grep translations (easy)
5. Is the cpio adjustment present in unstable?
6. Which architectures are covered by LSB and need an adjusted
kernel?
Conclusion:
Assuming that cpio is ok, sed and grep are either not used or will
be ok, it seems that that we can make woody LSB compliant ***IF***
all relevant kernels for all relevant architectures and all kernel
source pacakges will be adjusted.
This is a large if, since it took me more than a whole month to
get the kernel fixed security wise. I will not pester the people
again just for an LSB adjustment. And I will also run amok and
hunt down the first person who uploads an LSD adjusted kernel
package that overwrites a security update.
As I said before, either all packages go in together or not at
all. This means that some staging area is required. For this,
concentrate on kernel packages. Assuming alien, bash, grep, cpio,
pax and sed will be built in time by the buildd network, they can
be added late. It's also unlikely that they contain security
updates so that their update would interfere with security. It's
totally different for the kernel, looking at CAN-2003-0681,
CAN-2003-0985 and CAN-2004-0077.
Also please note that we cannot update the kernels in stable due
to broken modules dependencies and binary incompatibility introduced
by the ptrace fix. This does mainly affect i386 since no other
architecture makes heavy use of modules.
Also: This WILL NOT HAPPEN FOR THE r3 UPDATE
Also, if the above still won't/can't happen, an apt-get repository
with backports and stuff would be appropriate.
Regards,
Joey
PS: [1] Jeff, I hope you don't mind quoting your personal mail on this
subject publically.
PS: http://people.debian.org/~joey/3.0r3/ has been updated.
--
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum
Please always Cc to me when replying to me on the lists.
Reply to: