* 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
