Re: Heads-up: source compliance for D-I build dependencies

[Adeodato Simó <dato@net.com.org.es>]

* Frans Pop [Tue, 30 Sep 2008 11:38:50 +0200]:

> Maybe it could be an option to use the "transition upload block" mechanism 
> to prevent further uploads of (selected) D-I build dependencies to sid 
> and thus prevent version skew between testing and unstable.

I don't mind doing this for lenny, but I'll make a note to talk about
how this could be better done for squeeze. (But let's not start that
discussion now! </just-in-case>)

> A second related issue is that after the final D-I upload no updates for 
> packages that have udebs or are D-I build dependencies can be accepted 
> into testing, unless the version included in D-I is first saved in a 
> special suite. This last was done for a few packages for Etch.

> This is only true for udebs that are included in installer initrds, but as
> that varies per type of image and architecture it does need to be checked
> on a case-by-case basis.
> Examples: parted would be OK, openssh not.

Ok. (I'm sure it's clear that a package becomes "non-uploadable" by just being
included in a single one-arch/one-tpe combination.)

Can we get a list of these? (Or a pointer to one.)

> I've committed a simple script "check-compliance" in the scripts directory 
> of D-I SVN that parses the control file for build deps and uses rmadison 
> to get their versions. Below is the full list (with only deps for m68k 
> excluded). Packages marked with "*" have differing versions.

> Seems to me that libgcc1 is a definite problem [1] and that dosfstools, 
> palo and maybe tip22 are potential ones. upx-ucl is currently unused.

> I'll leave is to others to determine which of those are actually relevant 
> for source compliance. A lot of them obviously are not.
> I'll also leave it to others to decide whether or not to preventively 
> block uploads to unstable for certain build deps.

All I can do is block the necessary packages, and have a look at the
ones with different versions to see if they are suitable for migration,
or what should we do.

But, then, can some debian-boot person tell us (or work with us to find
out) what packages are in the "relevant for source compliance" category?


Anything else that I haven't replied to and that needed addressing,
please let me know.

Thanks,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                       Listening to: Joaquín Sabina - Hotel, dulce hotel