Bug#374288: shishi: FTBFS: Conflicting build dependencies.

[Simon Josefsson]

Steve Langasek <address@hidden> writes:

> On Mon, Jun 19, 2006 at 09:15:42AM -0700, Russ Allbery wrote:
>> Simon Josefsson <address@hidden> writes:
>> > Elrond <address@hidden> writes:
>
>> >> Can we make that
>> >> 
>> >>   libtasn1-3-dev | libtasn1-2-dev
>> >> 
>> >> to get a slight chance for backporting?
>
>> > I've installed this.  I assume that libtasn1-3-dev will be the first
>> > choice when Debian's build robots build the package?
>
>> > Objections to do this from anyone else?
>
>> Unfortunately, I believe the buildds are allowed to basically pick a
>> random choice among a string of alternatives.  (I think the logic goes
>> that the buildd may already have one of the packages installed, and hence
>> the dependency may be satisfied before something like apt gets at it.)
>
>> It's probably a bit safer to use just the dependency for unstable and ask
>> people doing backports to locally modify the build dependency.
>
> The implementation on the buildds is:
>
> - if one of the branches of the dependency is already satisfied, the
>   dependency is satisfied and nothing is done.
> - otherwise, install the first package in the list.
>
> So listing older compatible packages as alternative build-deps should be ok,
> because they should never be present on the buildds.  Listing alternatives
> that are still present in unstable (as libtasn1-2-dev) is less ok, since
> such a package may be pre-installed in the buildd chroot for whatever reason
> and cause a misbuild.

Thanks for the input.  Judging from some of the build logs:

http://buildd.debian.org/fetch.php?&pkg=shishi&ver=0.0.26-1&arch=s390&stamp=1150659548&file=log&as=raw
http://buildd.debian.org/fetch.php?&pkg=shishi&ver=0.0.26-1&arch=amd64&stamp=1150630076&file=log&as=raw

It seems like some buildds doesn't have libtasn1-3 at all, but
presumably has libtasn1-2.  So they would compile Shishi with it's
internal libtasn1 copy (since libtasn1-3 isn't available), leading to
problems if there are more security problems in libtasn1.  I.e., if we
need to make a security release of libtasn1, we'd also have to make a
security release for the shishi package, at least on those
architecture's that use the internal copy.

Since it doesn't seem simple to know that the buildds have the right
version installed, I've reverted this.  People doing backports will
have to remove the 'libtasn1-3-dev' dependency.

Thanks,
Simon