Re: depending on libssl1.0-dev, buildd fails to find it
Hi! On Mon, 2016-12-19 at 13:12:32 +0100, Johannes Schauer wrote: > Quoting Mattia Rizzolo (2016-12-18 11:38:24) > > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > > > As Arno hinted at, it's to have reliable builds. A transient inability > > > to install the first arm of an alternation should caused a dep-wait > > > state, not building with the alternate Build-Depends. > > > > which is kinda bullshit, as a different set of transitive > > build-dependencies can happen due to alternatives in the dependencies of > > any transitive build-dep, so the "have stable builds by removing > > alternatives in the build-dep list" is really pointless. > > For example ubuntu considers them to, there is just a switch in sbuild > > to have it consider them. The point has never been to try to get bit by bit reproducible builds, but to have a reproducible intent (on the same arch and across different arches), and no, it's not really pointless. So even though transitive build-dependencies or dependencies can certainly affect the end result, usually the direct build-dependencies are what supposedly has clear and direct impact when building the package. Say something like «libmariadb-dev | libmysql-dev», or «libssl-dev | libgnutls-dev». The code might support both, or might enable one plugin or another based on the present Build-Depends. And while transitive dependencies can indeed vary, they (in many, cases for languages that have a notion of dynamic loading/linking) should simply be implementation details, and things that could change back w/o affecting the package being built right now. > exactly my opinion as well. But it's even worse: > > Imagine you even directly build-depend on a virtual package. There is > currently > no way to somehow "reliably" always pick the same real provider of that > virtual > package. That's why we are not supposed to do that. :) As mentioned by Adam. > Can somebody remind me why we still want to have this behaviour as the > default? > And why whatever arguments speak *for* this behaviour being the default are > weighing more than the "unreliability" that is already introduced by > transitive > build dependencies and multiple providers of virtual build dependencies? As mentioned by James upthread, and from the previous explanation, it is to avoid having packages use the alternative dependencies, perhaps random ones if via virtuals, when the default and preferred one is f.ex. uninstallable due to a transition, or unavailable because it has not yet been built on this particular arch, etc. Thanks, Guillemm
Re: depending on libssl1.0-dev, buildd fails to find it
On Mon, Dec 19, 2016 at 01:12:32PM +0100, Johannes Schauer wrote: > Hi, > > Quoting Mattia Rizzolo (2016-12-18 11:38:24) > > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > > > As Arno hinted at, it's to have reliable builds. A transient inability > > > to install the first arm of an alternation should caused a dep-wait > > > state, not building with the alternate Build-Depends. > > > > which is kinda bullshit, as a different set of transitive > > build-dependencies can happen due to alternatives in the dependencies of > > any transitive build-dep, so the "have stable builds by removing > > alternatives in the build-dep list" is really pointless. > > For example ubuntu considers them to, there is just a switch in sbuild > > to have it consider them. > > exactly my opinion as well. But it's even worse: > > Imagine you even directly build-depend on a virtual package. There is > currently > no way to somehow "reliably" always pick the same real provider of that > virtual > package. Yes, you select the real provider as the first alternative. > I consider it very much as a nuisance to have this special mangling of > build-depends activated by default in sbuild. For example for dose3 we > introduced the --deb-emulate-sbuild option just because it was such a common > problem that dose3 would find a solution but sbuild was unable to because it > throws away all but the first alternative of the build dependencies. right. > Given that there exist transitive alternatives and virtual packages I'm also > questioning the effectiveness of this rule. I rather find it quite unexpected > and as Daniel's puzzlement shows rather a source of problems. > > Can somebody remind me why we still want to have this behaviour as the > default? Back in the olden days (and I'm talking << 2005 here, IIRC) the behaviour you're suggesting we move to *was* the default. It caused a never-ending nightmare of transition entanglements, because foo would depend on bar on one architecture, but on quux on the other, and then we do a binNMU and suddenly the dependency tree is completely different and the transition is broken yet again. We do *not* want to go back to that again. > And why whatever arguments speak *for* this behaviour being the default are > weighing more than the "unreliability" that is already introduced by > transitive > build dependencies and multiple providers of virtual build dependencies? Virtual build dependencies only work if you place a provider as a first alternative. > In my opinion we should either: > > - define a way that tells resolvers which "defaults" it should use for >resolving transitive alternatives and virtual packages for the purpose of >"stable" build dependency resolution That's *exactly* what we do today by placing one provider first. > - accept that dependency resolution given alternatives and virtual packages > is >always "unstable" and deal with the resulting bugs through changes in the >respective package metadata That's a horror. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: depending on libssl1.0-dev, buildd fails to find it
On Mon, Dec 19, 2016 at 09:13:25AM +0100, Daniel Pocock wrote: > Provides: libssl1.0-dev > > in the control file and would that ensure it works without tweaks? It might, but the proper way to fix it is: Build-Depends: libssl1.0-dev (>= 1.0.0) | libssl-dev (<< 1.1) i.e., put what's in unstable first, and the rest later. Then it'll work, also on backports. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: depending on libssl1.0-dev, buildd fails to find it
On 2016-12-19 12:12, Johannes Schauer wrote: Imagine you even directly build-depend on a virtual package. There is currently no way to somehow "reliably" always pick the same real provider of that virtual package. I'm not sure how that isn't exactly what you're doing by depending on "provider-of-virtual-package | virtual-package", as suggested by Policy 7.5 Regards, Adam
Re: depending on libssl1.0-dev, buildd fails to find it
Hi, Quoting Mattia Rizzolo (2016-12-18 11:38:24) > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > > As Arno hinted at, it's to have reliable builds. A transient inability > > to install the first arm of an alternation should caused a dep-wait > > state, not building with the alternate Build-Depends. > > which is kinda bullshit, as a different set of transitive > build-dependencies can happen due to alternatives in the dependencies of > any transitive build-dep, so the "have stable builds by removing > alternatives in the build-dep list" is really pointless. > For example ubuntu considers them to, there is just a switch in sbuild > to have it consider them. exactly my opinion as well. But it's even worse: Imagine you even directly build-depend on a virtual package. There is currently no way to somehow "reliably" always pick the same real provider of that virtual package. I consider it very much as a nuisance to have this special mangling of build-depends activated by default in sbuild. For example for dose3 we introduced the --deb-emulate-sbuild option just because it was such a common problem that dose3 would find a solution but sbuild was unable to because it throws away all but the first alternative of the build dependencies. Given that there exist transitive alternatives and virtual packages I'm also questioning the effectiveness of this rule. I rather find it quite unexpected and as Daniel's puzzlement shows rather a source of problems. Can somebody remind me why we still want to have this behaviour as the default? And why whatever arguments speak *for* this behaviour being the default are weighing more than the "unreliability" that is already introduced by transitive build dependencies and multiple providers of virtual build dependencies? In my opinion we should either: - define a way that tells resolvers which "defaults" it should use for resolving transitive alternatives and virtual packages for the purpose of "stable" build dependency resolution - accept that dependency resolution given alternatives and virtual packages is always "unstable" and deal with the resulting bugs through changes in the respective package metadata > > Now, backports are a different story because they use a different resolver > > which will pull in alternates. > > afaik sbuild strips the alternatives while parsing the .dsc (or > d/control or whatever), before passing the information to the resolvers, > so even if you use another resolver for -bpo you still get the same > behaviour. That is correct. cheers, josch signature.asc Description: signature
Re: depending on libssl1.0-dev, buildd fails to find it
Hi, Quoting James McCoy (2016-12-18 16:04:47) > On Sun, Dec 18, 2016 at 02:26:09PM +0100, Ondrej Novy wrote: > > Hi, > > > > 2016-12-18 14:14 GMT+01:00 James McCoy : > > > > Well, sbuild's man page documents that the aptitude resolver will check > > alternatives. If it doesn't in practice, that sounds like a bug. > > > > > > you need to run sbuild with "--resolve-alternatives" or add same option in > > sbuildrc. Imho bug in manpage. > > Quoth the man page: > > --build-dep-resolver=resolver >… The aptitude resolver is very similar, but smarter and >slower, and it will consider all alternatives by default; it >is suited to more complex situations, such as building >packages for the experimental distribution, where packages >need installing from multiple suites (unstable and >experimental). … > > --resolve-alternatives >Allow the use of alternatives in Build-Depends, >Build-Depends-Arch and Build-Depends-Indep. This is the >default for the aptitude dependency resolver. > > so there shouldn't be a need to use --resolve-alternatives with > --build-dep-resolver=aptitude. oh, that's interesting. I actually wasn't aware of that (I barely use the aptitude resolver). Do you think it makes sense for the RESOLVE_ALTERNATIVES configuration value to be different from the default for the aptitude resolver? Somehow I find this rather unexpected. If yes, then RESOLVE_ALTERNATIVES should be set to "true" for the aspcud resolver as well... Thanks! cheers, josch signature.asc Description: signature
Re: depending on libssl1.0-dev, buildd fails to find it
On 17/12/16 17:40, Christian Seiler wrote: > On 12/17/2016 04:49 PM, Daniel Pocock wrote: >> In my reSIProcate control[1] file, I included the following: >> >> Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... >> >> pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] >> >> In the buildd[3] report, it says that libssl-dev is uninstallable on >> every platform, it doesn't appear to try libssl1.0-dev >> >> Is buildd sensitive to the order of the dependencies when multiple >> options are given? Or is there some other glitch here? > > sbuild will always use the first alternative of build > dependencies. If you're doing this to make backporting easier, > then I'm afraid that won't work - you'll have to manually > change the B-D for backports. > I'm really hoping to focus my energy on upstream dev and reduce the effort for packaging. Adding another extra step for supporting backports doesn't feel good. Multiply this extra effort over all the packages that people backport and the net effect is that some people will stop backporting or will do it more slowly and the number of up-to-date backports we have may be slightly less than what it otherwise would be. There are similar problems with the change from libmysqlclient-dev to default-libmysqlclient-dev. Is it possible for a stable update of the jessie version of openssl to add something like this: Provides: libssl1.0-dev in the control file and would that ensure it works without tweaks? Regards, Daniel
Re: depending on libssl1.0-dev, buildd fails to find it
On Sun, Dec 18, 2016 at 02:26:09PM +0100, Ondrej Novy wrote: > Hi, > > 2016-12-18 14:14 GMT+01:00 James McCoy : > > Well, sbuild's man page documents that the aptitude resolver will check > alternatives. If it doesn't in practice, that sounds like a bug. > > > you need to run sbuild with "--resolve-alternatives" or add same option in > sbuildrc. Imho bug in manpage. Quoth the man page: --build-dep-resolver=resolver … The aptitude resolver is very similar, but smarter and slower, and it will consider all alternatives by default; it is suited to more complex situations, such as building packages for the experimental distribution, where packages need installing from multiple suites (unstable and experimental). … --resolve-alternatives Allow the use of alternatives in Build-Depends, Build-Depends-Arch and Build-Depends-Indep. This is the default for the aptitude dependency resolver. so there shouldn't be a need to use --resolve-alternatives with --build-dep-resolver=aptitude. The python-tornado backport didn't even make it to the buildd, so the issue you're seeing is probably related to wanna-build. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: depending on libssl1.0-dev, buildd fails to find it
Hi, 2016-12-18 14:14 GMT+01:00 James McCoy : > Well, sbuild's man page documents that the aptitude resolver will check > alternatives. If it doesn't in practice, that sounds like a bug. > you need to run sbuild with "--resolve-alternatives" or add same option in sbuildrc. Imho bug in manpage. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: depending on libssl1.0-dev, buildd fails to find it
On Dec 18, 2016 05:38, "Mattia Rizzolo" wrote: On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > Now, backports are a different story because they use a different > resolver which will pull in alternates. afaik sbuild strips the alternatives while parsing the .dsc (or d/control or whatever), before passing the information to the resolvers, so even if you use another resolver for -bpo you still get the same behaviour. Well, sbuild's man page documents that the aptitude resolver will check alternatives. If it doesn't in practice, that sounds like a bug. Cheers, James
Re: depending on libssl1.0-dev, buildd fails to find it
Hi, 2016-12-18 11:38 GMT+01:00 Mattia Rizzolo : > afaik sbuild strips the alternatives while parsing the .dsc (or > d/control or whatever), before passing the information to the resolvers, > so even if you use another resolver for -bpo you still get the same > behaviour. right: https://buildd.debian.org/status/package.php?p=python-tornado&suite=jessie-backports https://anonscm.debian.org/cgit/python-modules/packages/python-tornado.git/tree/debian/control#n24 python-tornado build-depends on missing: - python3:arm64 (>= 3.5) So jessie-backports buildd have this "bug" too. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: depending on libssl1.0-dev, buildd fails to find it
On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > As Arno hinted at, it's to have reliable builds. A transient inability > to install the first arm of an alternation should caused a dep-wait > state, not building with the alternate Build-Depends. which is kinda bullshit, as a different set of transitive build-dependencies can happen due to alternatives in the dependencies of any transitive build-dep, so the "have stable builds by removing alternatives in the build-dep list" is really pointless. For example ubuntu considers them to, there is just a switch in sbuild to have it consider them. > Now, backports are a different story because they use a different > resolver which will pull in alternates. afaik sbuild strips the alternatives while parsing the .dsc (or d/control or whatever), before passing the information to the resolvers, so even if you use another resolver for -bpo you still get the same behaviour. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: depending on libssl1.0-dev, buildd fails to find it
On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > Now, backports are a different story because they use a different > resolver which will pull in alternates. That's great to hear. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: depending on libssl1.0-dev, buildd fails to find it
On Sun, Dec 18, 2016 at 01:55:16AM +, Sean Whitton wrote: > Hello Christian, > > On Sat, Dec 17, 2016 at 05:40:49PM +0100, Christian Seiler wrote: > > On 12/17/2016 04:49 PM, Daniel Pocock wrote: > > > In my reSIProcate control[1] file, I included the following: > > > > > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > > > > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > > > > > In the buildd[3] report, it says that libssl-dev is uninstallable on > > > every platform, it doesn't appear to try libssl1.0-dev > > > > > > Is buildd sensitive to the order of the dependencies when multiple > > > options are given? Or is there some other glitch here? > > > > sbuild will always use the first alternative of build > > dependencies. If you're doing this to make backporting easier, > > then I'm afraid that won't work - you'll have to manually > > change the B-D for backports. > > Do you know why sbuild is ignoring alternative build-deps? As Arno hinted at, it's to have reliable builds. A transient inability to install the first arm of an alternation should caused a dep-wait state, not building with the alternate Build-Depends. Now, backports are a different story because they use a different resolver which will pull in alternates. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: depending on libssl1.0-dev, buildd fails to find it
Hello Christian, On Sat, Dec 17, 2016 at 05:40:49PM +0100, Christian Seiler wrote: > On 12/17/2016 04:49 PM, Daniel Pocock wrote: > > In my reSIProcate control[1] file, I included the following: > > > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > > > In the buildd[3] report, it says that libssl-dev is uninstallable on > > every platform, it doesn't appear to try libssl1.0-dev > > > > Is buildd sensitive to the order of the dependencies when multiple > > options are given? Or is there some other glitch here? > > sbuild will always use the first alternative of build > dependencies. If you're doing this to make backporting easier, > then I'm afraid that won't work - you'll have to manually > change the B-D for backports. Do you know why sbuild is ignoring alternative build-deps? -- Sean Whitton signature.asc Description: PGP signature
Re: depending on libssl1.0-dev, buildd fails to find it
On 12/17/2016 04:49 PM, Daniel Pocock wrote: > In my reSIProcate control[1] file, I included the following: > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > In the buildd[3] report, it says that libssl-dev is uninstallable on > every platform, it doesn't appear to try libssl1.0-dev > > Is buildd sensitive to the order of the dependencies when multiple > options are given? Or is there some other glitch here? sbuild will always use the first alternative of build dependencies. If you're doing this to make backporting easier, then I'm afraid that won't work - you'll have to manually change the B-D for backports. Regards, Christian
Re: depending on libssl1.0-dev, buildd fails to find it
Daniel Pocock writes: > In my reSIProcate control[1] file, I included the following: > > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > In the buildd[3] report, it says that libssl-dev is uninstallable on > every platform, it doesn't appear to try libssl1.0-dev > > Is buildd sensitive to the order of the dependencies when multiple > options are given? Or is there some other glitch here? Yes, sbuild only tries the first alternative, IIRC to keep the results reproducible. -- Arto Jantunen
depending on libssl1.0-dev, buildd fails to find it
In my reSIProcate control[1] file, I included the following: Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] In the buildd[3] report, it says that libssl-dev is uninstallable on every platform, it doesn't appear to try libssl1.0-dev Is buildd sensitive to the order of the dependencies when multiple options are given? Or is there some other glitch here? Regards, Daniel 1. https://sources.debian.net/src/resiprocate/1:1.11.0~alpha8-1/debian/control/ 2. https://packages.qa.debian.org/o/openssl1.0.html 3. https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
