On 2006-05-07 Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sat, May 06, 2006 at 06:41:42PM +0200, Andreas Metzler wrote: >> On 2006-04-18 Bastian Blank <[EMAIL PROTECTED]> wrote: >>> Package: gnutls13 >>> Version: 1.3.5 >>> Severity: grave
>>> A rebuild of gnutls13 looses its dependency against libtasn1 and uses a >>> staticaly linked version instead. [...] >> This is not fixable until libtasn >= 0.3.1 is uploaded, which will >> need to go through the NEW queue as the soname has changed. > Not necessarily. gnutls13 does build in the absence of libtasn-dev, it just > builds *differently* depending on whether libtasn1-3 is available: it uses > its bundled tasn instead. Eh. The whole bug report by Bastian basically just says: "It does not link against a externelly packages version of libtasn but statically against the included one." And this, .... > As long as there is no libtasn1-3 in the archive, > this should be ok (not great, but ok) -- so a reasonable solution might be > to drop the build-dependency on libtasn1-2-dev and instead build-conflict > with any libtasn dev packages that it could accidentally build against. > Then when there's a -dev package for libtasn1-3, it should be re-added as a > build-dependency. ... would not change what Bastian reported in *any* way. Removing the libtasn1-2 build-dependecy fixes the whishlist bug "lists pacages i build-depends that it does not use at all". Adding a build-conflict against libtasn1-2-dev seems to be useless. - Gnutls13's ./configure does check whether the tasn-library is new enough and if not will use the included version. No problem there. > Since gnutls11 and gnutls12 can *not* build against libtasn1-3, and we still > need those other versions in the archive for a while yet, it seems that the > new -dev package will need to be named libtasn1-3-dev to not overwrite the > libtasn1-2-dev package. This would give us build-conflicts with > libtasn1-3-dev now, Why? gnutls11 and gnutls12 build-depend on "libtasn1-3-dev" and libtasn1-3-dev and libtasn1-2-dev will need to conflict with each other. The Build-Conflict might be needed if gnutls11 and gnutls12 buid-depended on the virtual (and unused) package libtasn1-dev, but that s not the case. > and probably also a build-conflicts with libtasn1-2-dev to avoid the > problem with the libtasn1-2-dev 0.3 that was in the archive briefly. The broken version libtasn1-2-dev 0.3.1-1 would also conflict with gnutls13's build-dependency libtasn1-3-dev, so no problem. The conflict I can see to be necessary is for libtasn1-3 conflicting with broken libtasn1-2 (=0.3.1-1). > Then this would change to build-depends libtasn1-3-dev when the > time comes. > Given that there are already 53 source packages in the archive using > gnutls13 and no word on re-introducing libtasn1-3 in a way that avoids > breaking libtasn1-2, I would strongly encourage uploading this fix rather > than waiting for tasn1-3. As noted above I fail to see much of the necessity of the changes you propose and none of them changes "gnutls13 is linked statically against libtasn". - If you consider "gnutls13 is linked statically" to not be grave just downgrade this bug. I am sure I am missing something important[2] as I fail to see what is wrong with this straighforward approach: Upload new source package libtasn1-3 providing: libtasn1-3 (conflicts libtasn1-2 (=3.1-1)) libtasn1-3-dev (conflicts libtasn1-dev[1]) libtasn1-3-bin (actually it probably should be named libtasn1-bin) After it has been accepted and built upload a new version of gnutls13 with Build-Depends: libtasn1-3-dev cu andreas [1] It might also provide libtasn1-dev. [2] Symbols are versioned, so it has to be something else. -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
