Re: plastimatch/1.6.5+dfsg1-1 prep
On Tue, Dec 06, 2016 at 01:56:03PM +, Ghislain Vaillant wrote: > > > Both libblas-dev and libblas-dev | libblas.so would lead to successful > > > builds on autobuilders. The latter always pick libblas-dev in case an > > > alternative implementation is not already installed. > > > > OK, so there is no real point to change anything since I only use clean > > chroots for building (and expect others to do so as well at least before > > uploading, right? > > I'd say this change is probably not a reason for releasing a new iteration of > the package. However, not all users build from chroots and those would enjoy > being able to use their preferred BLAS implementation. OK, fine. Would you mind simply commiting your proposed change to Git to make sure it is done correctly (since I'm not fully sure whether I did understood you correctly). This makes sure it will not be forgotten next time. :-) Thanks a lot for your hints Andreas. -- http://fam-tille.de
Re: plastimatch/1.6.5+dfsg1-1 prep
On Tue, 2016-12-06 at 14:38 +0100, Andreas Tille wrote: > Hi again, > > On Tue, Dec 06, 2016 at 11:05:02AM +, Ghislain Vaillant wrote: > > > Hmmm, this message droped in my inbox after uploading. I'm not sure how > > > important this might be - in any case the package has built nicely. > > > > Both libblas-dev and libblas-dev | libblas.so would lead to successful > > builds on autobuilders. The latter always pick libblas-dev in case an > > alternative implementation is not already installed. > > OK, so there is no real point to change anything since I only use clean > chroots for building (and expect others to do so as well at least before > uploading, right? I'd say this change is probably not a reason for releasing a new iteration of the package. However, not all users build from chroots and those would enjoy being able to use their preferred BLAS implementation. > > It is only a big deal for local builds, where you might have a BLAS > > compatible package already installed (which provides libblas.so). For instance, there is a significant difference in build time for src:shark whether you build it with libblas-dev or libopenblas-dev. The testsuite runs much faster with the latter, but it is not available on all architectures. libblas-dev | libblas.so ensures that I can use OpenBLAS in local builds and NetLib's BLAS in chroots / autobuilders. Ghis
Re: plastimatch/1.6.5+dfsg1-1 prep
Hi again, On Tue, Dec 06, 2016 at 11:05:02AM +, Ghislain Vaillant wrote: > > Hmmm, this message droped in my inbox after uploading. I'm not sure how > > important this might be - in any case the package has built nicely. > > Both libblas-dev and libblas-dev | libblas.so would lead to successful > builds on autobuilders. The latter always pick libblas-dev in case an > alternative implementation is not already installed. OK, so there is no real point to change anything since I only use clean chroots for building (and expect others to do so as well at least before uploading, right? > It is only a big deal for local builds, where you might have a BLAS > compatible package already installed (which provides libblas.so). Thanks for the clarification Andreas. -- http://fam-tille.de
Re: plastimatch/1.6.5+dfsg1-1 prep
On Tue, 2016-12-06 at 11:01 +0100, Andreas Tille wrote: > Hi Ghislain, > > Other comments: > > > > - "Add libblas-dev dependency (sub-dependency of libdlib-dev) to > > plastimatch" > > > > If libdlib-dev is missing a dependency (BLAS), it should be fixed > > there. Transitive dependencies should not happen unless the dependency > > in question is optional (like a specific backend, or extra feature). > > > > If plastimatch directly depends on BLAS, then the right dependency > > should be libblas-dev | libblas.so, to allow any implementation of BLAS > > (netlib, atlas or openblas) to fulfill it. > > Hmmm, this message droped in my inbox after uploading. I'm not sure how > important this might be - in any case the package has built nicely. Both libblas-dev and libblas-dev | libblas.so would lead to successful builds on autobuilders. The latter always pick libblas-dev in case an alternative implementation is not already installed. > Could you please be more verbose what effect the additional dependency > might have? It is only a big deal for local builds, where you might have a BLAS compatible package already installed (which provides libblas.so). Ghis
Re: plastimatch/1.6.5+dfsg1-1 prep
Hi Ghislain, On Tue, Dec 06, 2016 at 08:00:50AM +, Ghislain Vaillant wrote: > > > > The more elegant way is to simply specify "any". Autobuilders will > > notice themselves whether a Build-Dependency exists or not and simply do > > nothing if a Build-Dependency is missing. > > I second this. > > I have a similar source package (asl) depending on VTK, which is also > not available on all architectures. It is marked any nonetheless and > has been built by the builders wherever all dependencies were > satisfiable. I've uploaded with Architecture: any. > Other comments: > > - "Add libblas-dev dependency (sub-dependency of libdlib-dev) to > plastimatch" > > If libdlib-dev is missing a dependency (BLAS), it should be fixed > there. Transitive dependencies should not happen unless the dependency > in question is optional (like a specific backend, or extra feature). > > If plastimatch directly depends on BLAS, then the right dependency > should be libblas-dev | libblas.so, to allow any implementation of BLAS > (netlib, atlas or openblas) to fulfill it. Hmmm, this message droped in my inbox after uploading. I'm not sure how important this might be - in any case the package has built nicely. Could you please be more verbose what effect the additional dependency might have? Kind regards Andreas. -- http://fam-tille.de
