Debian Bug report logs - #614413
Build-Depends: Buggy use of alternative dependencies

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Build-Depends: Buggy use of alternative dependencies

Date: Mon, 21 Feb 2011 20:26:25 +0000

Package: php5
Version: 5.3.5-1
Severity: important

php5 is using these alternative build dependencies:

automake (>= 1.11) | automake1.11
libcurl4-openssl-dev | libcurl-dev
libdb-dev (>= 4.7) | libdb4.8-dev | libdb4.6-dev,
libjpeg-dev | libjpeg62-dev
libmysqlclient-dev | libmysqlclient15-dev

The build dependency resolver is currently only using the first
alternative.  Newer resolvers use the other alternatives, and
this can potentially lead to inconsistency between builds.

Please only use one package, the one you specifically want for
the build, and drop the alternatives.  The use of alternatives
in build dependencies is not supported.  In particular, you really
only want one specific version of libdb (4.8?); there must be no
uncertainty about this when the build dæmon installs the build
dependencies.  The same thing applies to automake and the other
packages using alternatives.

This is an identified bug from from the whole archive rebuild
results at

  http://people.debian.org/~rleigh/squeeze-rebuild/report.pdf

php5_5.3.3-7:
    internal installs libdb-dev_4.8.
    Another transitional-like package where apt and aptitude pick
    the direct dependency rather than using a metapackage.


Thanks,
Roger

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Message #10 received at 614413@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: debian-devel@lists.debian.org

Subject: re buildd's resolver and package's build deps

Date: Mon, 21 Feb 2011 19:42:32 -0600

[explicit BCC to Roger]

Hi everyone, Roger,

Roger Leigh has filed a few bug reports related to how the buildd's resolver 
(either internal or any of the new ones: apt{,itude}) and I'm not sure I quiet 
agree.
Let's take for example the one filed against php5 [#614413]:

[...]
> Severity: important
> 
> php5 is using these alternative build dependencies:
> 
> automake (>= 1.11) | automake1.11
> libcurl4-openssl-dev | libcurl-dev
> libdb-dev (>= 4.7) | libdb4.8-dev | libdb4.6-dev,
> libjpeg-dev | libjpeg62-dev
> libmysqlclient-dev | libmysqlclient15-dev
> 
> The build dependency resolver is currently only using the first
> alternative.  Newer resolvers use the other alternatives, and
> this can potentially lead to inconsistency between builds.

Agreed that it can lead to build-deps inconsistencies.

> Please only use one package, the one you specifically want for
> the build, and drop the alternatives.  The use of alternatives
> in build dependencies is not supported.  In particular, you really
> only want one specific version of libdb (4.8?); there must be no
> uncertainty about this when the build dæmon installs the build
> dependencies.  The same thing applies to automake and the other
> packages using alternatives.

I disagree here.
Alternatives in build-* relationships *are* mentioned by policy. In fact, 
there's even an example in section 7.1.

There's also no stated guarantee *anywhere* (including release policy) that 
the package's build deps should be consistent, much less the result.

Also, alternatives have been used ever since I joined the project for making  
backporting easier. Requiring stricter build-deps also affects that use case.


After thinking about it for a while, my opinion is that if anyone wants 
consistency to be guaranteed (e.g. in php's case that a rebuild doesn't end up 
linking php to libdb4.6 instead of libdb4.8) it should be handled on 
buildd/release team's side. The build deps as provided by the source package 
are valid.

If the package fails to build because the dependencies were resolved in a non-
standard way then an RC bug should be filed and fixed.

I abhor the idea of uselessly tightening dependencies.

Regards,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #15 received at 614413@bugs.debian.org (full text, mbox, reply):

From: Sean Finney <seanius@debian.org>

To: debian-devel@lists.debian.org, 614413@bugs.debian.org

Subject: Re: [php-maint] Bug#614413: re buildd's resolver and package's build deps

Date: Wed, 23 Feb 2011 00:17:33 +0100

[Message part 1 (text/plain, inline)]

hi,

On Mon, 2011-02-21 at 19:42 -0600, Raphael Geissert wrote:
> I disagree here.
> Alternatives in build-* relationships *are* mentioned by policy. In fact, 
> there's even an example in section 7.1.
> 
> There's also no stated guarantee *anywhere* (including release policy) that 
> the package's build deps should be consistent, much less the result.
> 
> Also, alternatives have been used ever since I joined the project for making  
> backporting easier. Requiring stricter build-deps also affects that use case.

for the record, full ACK on raphael's statements (maybe the PHP packages
could use a bit of cleanup there post-squeeze-release though, but that'd
be severity: wishlist).

> After thinking about it for a while, my opinion is that if anyone wants 
> consistency to be guaranteed (e.g. in php's case that a rebuild doesn't end up 
> linking php to libdb4.6 instead of libdb4.8) it should be handled on 
> buildd/release team's side. The build deps as provided by the source package 
> are valid.

and we need *some* kind of predictable way to determine how they're
resolved for specifically that reason.  in the case of libdb, this is
actually pretty significant because other libdb-linking apps link to php
stuff (like, say, apache + apr + libapache-mod-php5), and we want
everything using the same version.  i would assume that "first given
should be default" should be reasonable enough, and on the rare chance
that something breaks, we get it handled with a binNMU or subsequent
upload.

i think the backport branching argument from roger is valid in the
hypothetical sense, but i think there's a number of maintainers who
support backporting only to the point that someone else is doing it and
all they have to do is add some alternate build-deps, and they probably
wouldn't bother otherwise.  

in the case of php, for example, i would hurl expletives at anyone who
suggested that we start supporting yet another branch (and subsequently
ask them if they were interested in "joining" pkg-php, muwahaha) 

backwards-compatible can also mean forwards-compatible too, which i
suppose might make a package binNMU'able in some kind of transition
where it would otherwise be needing a sourceful upload.


anyway, just my 0.02 $LC_MONETARY fwiw :)

	sean

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 614413@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@debian.org>

To: Roger Leigh <rleigh@debian.org>, 614413@bugs.debian.org

Subject: Re: [php-maint] Bug#614413: Bug#614413: re buildd's resolver and package's build deps

Date: Thu, 17 Mar 2011 11:56:59 +0100

tags 614413 +wontfix
thank you

Hi,

just to reconfirm our position - I'm here with Sean and Raphael. (And
BTW: Roger, very good work on that report, we just don't agree with
the conclusion ;)).

Ondrej

On Wed, Feb 23, 2011 at 00:17, Sean Finney <seanius@debian.org> wrote:
> hi,
>
> On Mon, 2011-02-21 at 19:42 -0600, Raphael Geissert wrote:
>> I disagree here.
>> Alternatives in build-* relationships *are* mentioned by policy. In fact,
>> there's even an example in section 7.1.
>>
>> There's also no stated guarantee *anywhere* (including release policy) that
>> the package's build deps should be consistent, much less the result.
>>
>> Also, alternatives have been used ever since I joined the project for making
>> backporting easier. Requiring stricter build-deps also affects that use case.
>
> for the record, full ACK on raphael's statements (maybe the PHP packages
> could use a bit of cleanup there post-squeeze-release though, but that'd
> be severity: wishlist).
>
>> After thinking about it for a while, my opinion is that if anyone wants
>> consistency to be guaranteed (e.g. in php's case that a rebuild doesn't end up
>> linking php to libdb4.6 instead of libdb4.8) it should be handled on
>> buildd/release team's side. The build deps as provided by the source package
>> are valid.
>
> and we need *some* kind of predictable way to determine how they're
> resolved for specifically that reason.  in the case of libdb, this is
> actually pretty significant because other libdb-linking apps link to php
> stuff (like, say, apache + apr + libapache-mod-php5), and we want
> everything using the same version.  i would assume that "first given
> should be default" should be reasonable enough, and on the rare chance
> that something breaks, we get it handled with a binNMU or subsequent
> upload.
>
> i think the backport branching argument from roger is valid in the
> hypothetical sense, but i think there's a number of maintainers who
> support backporting only to the point that someone else is doing it and
> all they have to do is add some alternate build-deps, and they probably
> wouldn't bother otherwise.
>
> in the case of php, for example, i would hurl expletives at anyone who
> suggested that we start supporting yet another branch (and subsequently
> ask them if they were interested in "joining" pkg-php, muwahaha)
>
> backwards-compatible can also mean forwards-compatible too, which i
> suppose might make a package binNMU'able in some kind of transition
> where it would otherwise be needing a sourceful upload.
>
>
> anyway, just my 0.02 $LC_MONETARY fwiw :)
>
>        sean
>
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
>



-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/

Message #27 received at 614413@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Ondřej Surý <ondrej@debian.org>

Cc: Roger Leigh <rleigh@debian.org>, 614413@bugs.debian.org

Subject: Re: [php-maint] Bug#614413: Bug#614413: re buildd's resolver and package's build deps

Date: Thu, 17 Mar 2011 12:09:30 +0000

[Message part 1 (text/plain, inline)]

On Thu, Mar 17, 2011 at 11:56:59AM +0100, Ondřej Surý wrote:
> tags 614413 +wontfix
> thank you
> 
> Hi,
> 
> just to reconfirm our position - I'm here with Sean and Raphael. (And
> BTW: Roger, very good work on that report, we just don't agree with
> the conclusion ;)).

Hi Ondřej,

That's fine.  I don't know if you saw the discussion on -devel and
-policy, but I have since revised this opinion in light of the
discussion, and this isn't a bug at all.  Feel free to close it
entirely :)

We subsequently adjusted the apt resolver to behave in the same way
as the internal resolver; that is, it prunes all alternatives and
only considers the first one, making it perfectly acceptable to use
alternatives.  (The behaviour is configurable; aptitude considers all
alternatives by default, so the alternatives can be used when building
e.g. experimental and backports, but won't be used for unstable.)

The only known difference now is that internal would skip the first
alternative if any of the alternatives were already installed.  apt
will still require the first to be present.  This difference will
only be seen if building in a dirty build environment, and nowadays
we use clean chroot snapshots so it won't be seen in practice.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 614413@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@debian.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 614413@bugs.debian.org

Subject: Re: [php-maint] Bug#614413: Bug#614413: re buildd's resolver and package's build deps

Date: Thu, 17 Mar 2011 15:07:34 +0100

close 614413
thank you

Roger,

thanks for heads-up. I am unable to keep up with debian-devel, so
thank you for the summary. This is a good news :). Closing the bug.

Ondrej

On Thu, Mar 17, 2011 at 13:09, Roger Leigh <rleigh@codelibre.net> wrote:
> On Thu, Mar 17, 2011 at 11:56:59AM +0100, Ondřej Surý wrote:
>> tags 614413 +wontfix
>> thank you
>>
>> Hi,
>>
>> just to reconfirm our position - I'm here with Sean and Raphael. (And
>> BTW: Roger, very good work on that report, we just don't agree with
>> the conclusion ;)).
>
> Hi Ondřej,
>
> That's fine.  I don't know if you saw the discussion on -devel and
> -policy, but I have since revised this opinion in light of the
> discussion, and this isn't a bug at all.  Feel free to close it
> entirely :)
>
> We subsequently adjusted the apt resolver to behave in the same way
> as the internal resolver; that is, it prunes all alternatives and
> only considers the first one, making it perfectly acceptable to use
> alternatives.  (The behaviour is configurable; aptitude considers all
> alternatives by default, so the alternatives can be used when building
> e.g. experimental and backports, but won't be used for unstable.)
>
> The only known difference now is that internal would skip the first
> alternative if any of the alternatives were already installed.  apt
> will still require the first to be present.  This difference will
> only be seen if building in a dirty build environment, and nowadays
> we use clean chroot snapshots so it won't be seen in practice.
>
>
> Regards,
> Roger
>
> --
>  .''`.  Roger Leigh
>  : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
>  `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
>   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk2B+foACgkQVcFcaSW/uEjdQACg8rW7qNsbtCQQ5S/EpVgqVgxM
> 66oAoO9/evKem4Ob/PC5BHPFklD82/MJ
> =WTYw
> -----END PGP SIGNATURE-----
>
>



-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/

Message #35 received at 614413-done@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@sury.org>

To: 548015-done@bugs.debian.org, 546164-done@bugs.debian.org, 599078-done@bugs.debian.org, 509652-done@bugs.debian.org, 614413-done@bugs.debian.org

Subject: php5: BTS cleanup

Date: Mon, 11 Apr 2011 00:19:16 +0200

Hi,

I am just closing couple of old bugs for version no longer present in
the stable or unstable release.

O.
-- 
Ondřej Surý <ondrej@sury.org>

Send a report that this bug log contains spam.