[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Source compliance for D-I build dependencies: follow-up


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          |          |          | 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.)


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
                -- 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.


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
            echo "(select '$pkg' as package"
            echo "UNION ALL select '$pkg'"
    echo ")"


cat <<EOF
D-I build-dependencies


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'
       as ok
  -- 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;

# vi: et

Reply to: