Bug#614413: [php-maint] Bug#614413: Bug#614413: re buildd's resolver and package's build deps
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 sean...@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-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint -- Ondřej Surý ond...@sury.org http://blog.rfc1925.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614413: [php-maint] Bug#614413: Bug#614413: re buildd's resolver and package's build deps
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 Description: Digital signature
Bug#614413: [php-maint] Bug#614413: Bug#614413: re buildd's resolver and package's build deps
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 rle...@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ý ond...@sury.org http://blog.rfc1925.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614413: [php-maint] Bug#614413: re buildd's resolver and package's build deps
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 Description: This is a digitally signed message part
Bug#614413: re buildd's resolver and package's build deps
[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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
