On 15/08/14 12:53 PM, Daniel Baumann wrote: > On 08/15/2014 02:52 PM, Ben Armstrong wrote: >> has been breaking them for months[0] because it fails to >> exclude certain packages that tasksel excludes (those that are >> either in a 'lib' section or non-main section). > i still think that this is a very wrong way to do it and we should never > ever have a corrupted archive like that, in the sense that a new version > of a package should not be able to enter testing if some other package > is still (versioned) depending on some previous package to the effect > that two version of the same package are now in a suite at the same time.
Understood ... > this is begging for troubles and is shouldn't be that the clients (apt, > or even more higher level like tasksel here) need to handle that. > instead the archive software (dak) should do that, it is supposed to > guarantee the consistency of the archive. i've somewhat tried to argue > that, but unsurprisingly that hasn't gained any interest (#751429). Yeah. I can think of two other ways that could've solved it. One would be to make db5.1-util Provide: libdb5.1. I was frankly disappointed it wasn't. The other would be to no longer make the old libdb5.1 standard (but I understand if the maintainers hardly thought that was worth another upload for, since it seemed like "real soon now" it was going to be dropped from the archive). > having said that.. since we fail to make other people fix their stuff, > we'll need to workaround it yet another time on our end. Yeah, I don't think that's ever going to happen, as it takes time for stuff that no longer depends on the old stuff to migrate to testing so that the old stuff can be dropped ... that's just something that we have no control over. So I agree, we need a workaround ... > since the original problem of the inconsistent archive still remains, > and the code in question is not at all performance critical in any way, > i suggest we do two things: > > a) apply your patch "unconditionally" (= use the excludes by default and > leave it at that) > > b) on top of that, extend it to do a two-times grep-dctrl (one with the > excludes, one without the excludes) and show the difference if any. > therefore, we'll have it in the build log so user could (potentially) > spot any errors/surprises from it. Sounds good to me. But do we really need to do b)? Or just document in the code how to do it if you need to see the difference ... yagni? I doubt if *anyone* uses this helper but us, for standard. Ben -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
