Re: Finding out why a Build-Dependency is fetched.
On Thu, Dec 20, 2007 at 12:23:49PM +0530, Kumar Appaiah wrote: Well, I've filed one already with a patch and severity serious! It does affect common behaviour from earlier though. Let me downgrade it if it comes to that, or the maintainer objects. OK, the verdict from #457151 is that ordering of Build-Depends must not be relied upon, and Build-Conflicts is the way to go. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
Hello, On Thu, 20 Dec 2007, Kumar Appaiah wrote: In other words, if you specifically do not want atlas3-base-dev to be present during the build then you should put it in Build-Conflicts. I am aware, but want to avoid it. It may not be avoidable. See http://lists.debian.org/debian-devel/2007/07/msg00588.html Unless your package has the possibility of a configure option like --without-atlas, your only way to prevent atlas dependency being configured during the build is to conflict with it. Of course, it would be nice if pbuilder would avoid installing un-needed dependencies, especially when one is running the build on a small machine which does not have a very high-speed network link. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Finding out why a Build-Dependency is fetched.
Dear Debian Mentors, This is with reference to a package of mine, libitpp, whose latest version I have packaged and it is available at: http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_4.0.1-2.dsc What I want to know is, earlier builds never pulled in atlas3-base-dev for the build, as you may see here: http://buildd.debian.org/fetch.cgi?pkg=libitpparch=i386ver=4.0.0-3stamp=1193598381file=logas=raw Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for the build, and my package now depends on atlas3-base. The same thing happens on amd64 (thanks to William Pitcock for testing it for me). Despite my best efforts, I am unable to spot what is causing atlas to be pulled in. I do observe that lapack3-dev has the following dependencies: Depends: lapack3 (= 3.0.2531a-6.1), libc6-dev, atlas3-base-dev | refblas3-dev | libblas-3.so, g77 However, libitpp uses the following dependencies: Build-Depends: debhelper (= 5), autotools-dev, doxygen (= 1.5.1-1), refblas3-dev, libfftw3-dev, texlive-latex-base, gs, lapack3-dev Clearly, refblas3-dev is provided, so lapack3-dev shouldn't need atlas3-base-dev, right? What am I missing? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
(Annotation at the end) On Thu, Dec 20, 2007 at 10:30:14AM +0530, Kumar Appaiah wrote: Dear Debian Mentors, This is with reference to a package of mine, libitpp, whose latest version I have packaged and it is available at: http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_4.0.1-2.dsc What I want to know is, earlier builds never pulled in atlas3-base-dev for the build, as you may see here: http://buildd.debian.org/fetch.cgi?pkg=libitpparch=i386ver=4.0.0-3stamp=1193598381file=logas=raw Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for the build, and my package now depends on atlas3-base. The same thing happens on amd64 (thanks to William Pitcock for testing it for me). Despite my best efforts, I am unable to spot what is causing atlas to be pulled in. I do observe that lapack3-dev has the following dependencies: Depends: lapack3 (= 3.0.2531a-6.1), libc6-dev, atlas3-base-dev | refblas3-dev | libblas-3.so, g77 However, libitpp uses the following dependencies: Build-Depends: debhelper (= 5), autotools-dev, doxygen (= 1.5.1-1), refblas3-dev, libfftw3-dev, texlive-latex-base, gs, lapack3-dev Clearly, refblas3-dev is provided, so lapack3-dev shouldn't need atlas3-base-dev, right? What am I missing? FWIW, I observe a similar happening with octave2.9. The Build-Depends haven't change significantly, but all of a sudden, atlas is coming in: Without Atlas on Sparc: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.17-1arch=sparcstamp=1195174810file=log With Atlas on Sparc: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.19-1arch=sparcstamp=1197772112file=log Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
Hello, On Thu, 20 Dec 2007, Kumar Appaiah wrote: Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for the build, and my package now depends on atlas3-base. The building of a package should not produce a different package if some additional packages not listed in Build-Conflicts are installed. In other words, if you specifically do not want atlas3-base-dev to be present during the build then you should put it in Build-Conflicts. I know that this does not explain why pbuilder is behaving the way it is but it seems to be a solution. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Finding out why a Build-Dependency is fetched.
On 07/12/20 10:30 +0530, Kumar Appaiah said ... What I want to know is, earlier builds never pulled in atlas3-base-dev for the build, as you may see here: http://buildd.debian.org/fetch.cgi?pkg=libitpparch=i386ver=4.0.0-3stamp=1193598381file=logas=raw This could just mean that atlas3-base-dev has been added to the dependencies of a package that you build-depend on. Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for Is your environment up-to-date? Did you ensure that you have all the latest packages (in particular, those that you build-depend on) from unstable? With pbuilder, you are using the latest. be pulled in. I do observe that lapack3-dev has the following dependencies: Depends: lapack3 (= 3.0.2531a-6.1), libc6-dev, atlas3-base-dev | refblas3-dev | libblas-3.so, g77 However, libitpp uses the following dependencies: Build-Depends: debhelper (= 5), autotools-dev, doxygen (= 1.5.1-1), refblas3-dev, libfftw3-dev, texlive-latex-base, gs, lapack3-dev Clearly, refblas3-dev is provided, so lapack3-dev shouldn't need atlas3-base-dev, right? What am I missing? I would say that the order of resolving dependencies may be different for different programs. Consider this: Option 1: You install refblas3-dev and then lapack3-dev, so atlas3-base-dev is not brought in because refblas3-dev exists. Option 2: The buildd gets the lapack3-dev and hence atlas3-base-dev first and then it gets refblas3-dev. But, when you build the package, if there is a check (maybe via the configure script) for atlas3-base-dev and then for refblas3-dev, in Option 1, refblas3-dev is used and in Option 2 atlas3-base-dev is used. (I did not verify the above, but this is a possible explanation). If you want to avoid the above, you should Build-Depends: lapack3-dev | refblas3-dev. You should be good with just a Build-Depends: lapack3-dev but the | refblas3-dev helps backporters (if lapack3 doesn't depend on refblas3-dev in its older versions). Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
Hi! On Thu, Dec 20, 2007 at 10:56:46AM +0530, Kapil Hari Paranjape wrote: The building of a package should not produce a different package if some additional packages not listed in Build-Conflicts are installed. In other words, if you specifically do not want atlas3-base-dev to be present during the build then you should put it in Build-Conflicts. I am aware, but want to avoid it. I know that this does not explain why pbuilder is behaving the way it is but it seems to be a solution. Well, here's a further diagnosis. For some reason, the order of installed packages in the buildds (and my pbuilder) are being reordered in alphabetical order. See this old log. The apt-get command follows the same order as specified in the package's Build-Depends: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.17-1arch=sparcstamp=1195174810file=log But here, it is in alphabetical order: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.19-1arch=sparcstamp=1197772112file=log And I saw the source package for octave2.9, here's the control: Build-Depends: g++-4.1 (= 4.1.1-4), debhelper (= 5.0.0), autoconf, texinfo, texlive-latex-base, texlive-generic-recommended, g77, libreadline5-dev, libncurses5-dev, gperf, libhdf5-serial-dev (= 1.6.5) | libhdf5-lam-dev (= 1.6.5) | libhdf5-mpich-dev (= 1.6.5), refblas3-dev | atlas3-base-dev, lapack3-dev | atlas3-base-dev, gnuplot-nox, fftw3-dev, texi2html, less, dpatch, slice, libpcre3-dev, flex, libglpk-dev (= 4.15), libsuitesparse-dev, gawk, gs-gpl, libcurl4-dev, libqhull-dev, desktop-file-utils Notice that refblas3-dev is _before_ lapack3-dev. Now, if apt-get is called faithfully in this order, atlas does not come in. But if it is reordered, the lapack3-dev dependencies are honoured first, and that pulls in atlas3-base, which is the first alternate dependency, and is satisfiable. Now, the question is, where is the reordering occurring? sbuild? Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On Thu, Dec 20, 2007 at 11:49:53AM +0530, Kumar Appaiah wrote: See this old log. The apt-get command follows the same order as specified in the package's Build-Depends: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.17-1arch=sparcstamp=1195174810file=log But here, it is in alphabetical order: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.19-1arch=sparcstamp=1197772112file=log And I saw the source package for octave2.9, here's the control: Build-Depends: g++-4.1 (= 4.1.1-4), debhelper (= 5.0.0), autoconf, texinfo, texlive-latex-base, texlive-generic-recommended, g77, libreadline5-dev, libncurses5-dev, gperf, libhdf5-serial-dev (= 1.6.5) | libhdf5-lam-dev (= 1.6.5) | libhdf5-mpich-dev (= 1.6.5), refblas3-dev | atlas3-base-dev, lapack3-dev | atlas3-base-dev, gnuplot-nox, fftw3-dev, texi2html, less, dpatch, slice, libpcre3-dev, flex, libglpk-dev (= 4.15), libsuitesparse-dev, gawk, gs-gpl, libcurl4-dev, libqhull-dev, desktop-file-utils Notice that refblas3-dev is _before_ lapack3-dev. Now, if apt-get is called faithfully in this order, atlas does not come in. But if it is reordered, the lapack3-dev dependencies are honoured first, and that pulls in atlas3-base, which is the first alternate dependency, and is satisfiable. Now, the question is, where is the reordering occurring? sbuild? And the answer is, that the dsc file itself has it ordered! The generated dsc file has ordered B-Deps. I think this has to do with the dpkg-dev refactoring. I'll find out if a bug is warranted, though I'd appreciate more input. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On 07/12/20 12:04 +0530, Kumar Appaiah said ... On Thu, Dec 20, 2007 at 11:49:53AM +0530, Kumar Appaiah wrote: Notice that refblas3-dev is _before_ lapack3-dev. Now, if apt-get is called faithfully in this order, atlas does not come in. But if it is reordered, the lapack3-dev dependencies are honoured first, and that pulls in atlas3-base, which is the first alternate dependency, and is satisfiable. Now, the question is, where is the reordering occurring? sbuild? And the answer is, that the dsc file itself has it ordered! The generated dsc file has ordered B-Deps. I think this has to do with the dpkg-dev refactoring. I'll find out if a bug is warranted, though I'd appreciate more input. IMO, this isn't a bug. The order in which packages are listed in the build-depends shouldn't matter. Build-Depends: lapack3-dev | refblas3-dev or Build-Depends: refblas3-dev | lapack3-dev (if you please) is what you want to use really. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On Thu, Dec 20, 2007 at 12:01:24PM +0530, Y Giridhar Appaji Nag wrote: IMO, this isn't a bug. The order in which packages are listed in the build-depends shouldn't matter. Build-Depends: lapack3-dev | refblas3-dev or Build-Depends: refblas3-dev | lapack3-dev (if you please) is what you want to use really. Well, I've filed one already with a patch and severity serious! It does affect common behaviour from earlier though. Let me downgrade it if it comes to that, or the maintainer objects. And no. I want to Build-Depend on BOTH lapack3-dev and refblas3-dev, and not one of them. I don't want atlas3 coming in. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
