Source compliance for D-I build dependencies: follow-up
Hello,
this is a very late follow-up, but apparently just in time, to [1]. I'm
very sorry about the delay (though I never got the follow-up Otavio
promised). Here's a draft of what I think is needed, we'd appreciate if
you (-boot) could go over it, both the general lines and the details,
and tell us whether you belive it to be complete and enough.
[1]: http://lists.debian.org/debian-release/2008/09/msg01266.html
The easy part is the handling of udeb-providing packages: we we'll just
wait, as usual, for d-i RM ack/nack before unblocking. If an update
*must* get through, and d-i RM acks it, we'll just copy the previous
version to a special suite as it was done in Etch. (We will copy the
source and the udeb only, not the regular packages. This is what was
done in Etch, and it makes sense that is correct. Please speak up if
it's not.)
Now, for the less easy part: code that gets embedded. Steve Langasek has
kindly provided us with an initial draft for the list of packages that
should be checked [2]. This is a subset of D-I's build-dependencies,
those where he knew the requirement applied. (His list included m68k
packages, I've dropped those. He's also unsure about some arm packages,
it'd be great to receive confirmation about them. I also changed
glibc-pic, which is a virtual package, to the ones providing it.)
[2]: http://minbar.dodds.net/~vorlon/sync-d-i-build-deps.txt
Please find below the list of those packages with their versions in
testing and unstable. It would be really great if you could check it,
and see if more packages need to be added to it. See below about this.
Regarding those packages not in sync, both arcboot and mkvmlinuz are a
translation-only upload, so I'll unblock them. As for gcc-4.3, I think
4.3.2-2 is Lenny material, I'll check with doko.
package | source | testing | unstable | ok
---------------+---------------+-------------------+-------------------+-----
libgcc1 | gcc-4.3 | 4.3.2-1.1 | 4.3.2-2 | no
mkvmlinuz | mkvmlinuz | 34 | 35 | no
tip22 | arcboot | 0.3.11 | 0.3.12 | no
aboot | aboot | 1.0~pre20040408-3 | 1.0~pre20040408-3 | yes
apex-nslu2 | apex | 1.4.15.2 | 1.4.15.2 | yes
bf-utf-source | bf-utf | 0.05-0.1 | 0.05-0.1 | yes
colo | colo | 1.22-1 | 1.22-1 | yes
elilo | elilo | 3.8-1 | 3.8-1 | yes
genisovh | genisovh | 0.1-3 | 0.1-3 | yes
libc6-pic | glibc | 2.7-18 | 2.7-18 | yes
libc6.1-pic | glibc | 2.7-18 | 2.7-18 | yes
libnewt-pic | newt | 0.52.2-11.3 | 0.52.2-11.3 | yes
libslang2-pic | slang2 | 2.1.3-3 | 2.1.3-3 | yes
nwutil | nwutil | 1.8-2 | 1.8-2 | yes
palo | palo | 1.16+nmu1 | 1.16+nmu1 | yes
sibyl | sibyl | 2.4.2-2 | 2.4.2-2 | yes
slugimage | slugimage | 1:0.0+r104-5 | 1:0.0+r104-5 | yes
sparc-utils | sparc-utils | 1.9-4 | 1.9-4 | yes
syslinux | syslinux | 2:3.71+dfsg-5 | 2:3.71+dfsg-5 | yes
uboot-mkimage | uboot-mkimage | 0.4 | 0.4 | yes
upx-ucl | upx-ucl | 3.01-3 | 3.01-3 | yes
yaboot | yaboot | 1.3.13a-1 | 1.3.13a-1 | yes
This list is generated directly from ftp-master's database, in what
started as a very simple SQL query, and then got, uhm, less simple. I
did this because it's more effective not to query projectb over http.
The script is attached.
I'm happy to do with this script whatever -boot prefers: run it on
ftp-master for d-i team to use its output, or donate it for you to run
yourselves on merkel (in this case, I volunteer to maintain the SQL
part, and whatever bits are needed; but it wouldn't be difficult to find
more SQL-savy people around in Debian, so it's in now way only
maintenable by me).
Adding packages is just a matter of adding a line to the script.
*Eventually*, I think it would be very good if the list could be
obtained directly from the debian-installer source package. I see that
the build-dependency list for d-i is extensively commented. If you wish,
maybe you could add a line in a pre-defined format that signals "this
build-dependency must be in sync". If you do that, I'd be happy to
extend the script to parse that information. (Or it can be changed to
just accept a list of packages on stdin, and you can parse your
build-dependencies yourselves, as you wish.)
Thoughts?
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
- Why are you whispering?
- Because I just think that no matter where she is, my mom can hear this
conversation.
-- Rory and Lane
#! /bin/bash
#
# Print a list of binary packages and their versions in testing and
# unstable, and whether they differ or not.
#
# Copyright (c) 2009 Adeodato Simó (dato@net.com.org.es)
# Licensed under the terms of the MIT license.
PKGLIST="
aboot
apex-nslu2
bf-utf-source
colo
elilo
genisovh
libc6-pic
libc6.1-pic
libgcc1
libnewt-pic
libslang2-pic
mkvmlinuz
nwutil
palo
sibyl
slugimage
sparc-utils
syslinux
tip22
uboot-mkimage
upx-ucl
yaboot
"
make_table() {
# This could be just a VALUES expression, but PostgreSQL 8.1 does
# not support them.
local pkg
local first="yes"
for pkg in $1; do
if [ "$first" = "yes" ]; then
first="no"
echo "(select '$pkg' as package"
else
echo "UNION ALL select '$pkg'"
fi
done
echo ")"
}
##
cat <<EOF
D-I build-dependencies
======================
EOF
psql projectb <<EOF
select package, source, testing, unstable,
case when (testing is NULL or unstable is NULL)
then 'no'
else case when (versioncmp(testing, unstable) = 0)
then 'yes'
else 'no'
end
end
as ok
from
-- We do the binary-based selection against unstable, because some
-- binary packages may be out of date there, and we want to catch
-- those. We later join against testing based on source package name.
-- We use "right join PKGLIST" in addition "where package in PKGLIST"
-- so that it's clear if some package in the list could not be found
-- in the database. (We don't do the join *only* because duplicating
-- it is sensibly faster.)
(select package, s.source, s.version as unstable
from binaries p, source s, suite su, bin_associations ba
where p.source = s.id and p.id = ba.bin and
ba.suite = su.id and su.suite_name = 'unstable' and
p.package in `make_table "$PKGLIST"`
group by package, s.source, s.version) s1
right join `make_table "$PKGLIST"` as pkglist using(package)
-- A left join allows us to find packages that are in unstable but
-- not in testing.
left join
(select source, s.version as testing
from source s (src_id, source, version)
natural join src_associations sa (sa_id, suite_id, src_id)
join suite su (suite_id, suite_name) using (suite_id)
where suite_name = 'testing') s2
using (source)
order by ok, package;
EOF
# vi: et
Reply to: