On Mon, May 08, 2006 at 04:23:47PM +0200, Andreas Metzler wrote:
> 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, ....

Actually, the title of the bug report is "rebuild loses dep against
libtasn1", which is very much about whether the build-dependencies are
correct.

> > 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

It's not useless.  The libtasn1-2-dev 0.3 that was briefly in the archive is
what the gnutls13 packages on i386 and s390 got built against.  While this
package will no longer be found on any of the buildds, in the interest of
preventing accidental misbuilds on developer systems the build-conflict
ought to be added.

Limiting the build-conflict to the specific broken version of libtasn1-2-dev
should be fine, if you want to take that approach.

> Gnutls13's ./configure does check whether the tasn-library is new
> enough and if not will use the included version. No problem there.

The problem is precisely that this makes our builds non-deterministic, which
is bad; we don't want internal libraries to be either enabled or disabled
due to accidents of the build environment.

> > 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).

gnutls13 does not *have* a build-dependency on libtasn1-3-dev, and *cannot*
have one until the new libtasn1-3-dev is uploaded.  I'm proposing a fix for
gnutls13 that can be implemented now instead of later.

> 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.

Wrong build-dependencies/build-conflicts are a serious 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

This is fine, but only the maintainer can upload the new libtasn1-3.  Are
you offering to maintain this package?

I'm not willing to maintain it.  Adding build-conflicts in gnutls13 is
something that I can do in an NMU to fix this bug now.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
[EMAIL PROTECTED]                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply via email to