Re: Source compliance for D-I build dependencies: follow-up
* Adeodato Simó [Fri, 16 Jan 2009 11:32:12 +0100]:
> 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
> ---------------+---------------+-------------------+-------------------+-----
Oh, I didn't comment what's the plan if we must update one of these
packages. I think the same approach as above, copying to an extra suite,
should work, right? Additionally, once we have a definitive list, I will
apply one of the "transitions" blocks, as we mentioned back in October.
Sounds okay?
Btw, I don't know if it'd be a viable approach or not, but I'll mention
it nevertheless: I wonder if for squeeze we should do the debian-installer
uploads to t-p-u instead of unstable. We would still have to ensure
source compliance, by copying if an update in testing must happen, but
we would stop caring if unstable and testing are in sync.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Everything you read in newspapers is absolutely true, except for that
rare story of which you happen to have first-hand knowledge.
-- Erwin Knoll
Reply to: