Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On Thu, Jun 21, 2012 at 09:37:03AM +0200, Wouter Verhelst wrote: > On Sun, Jun 17, 2012 at 02:00:04PM +0200, Joachim Breitner wrote: > > Hi, > > > > it seems that my idea is not well received; point taken, and I do like > > the alternative about debian/rules creating debian/control in the clean > > target. > > Do. Not. Do. That. > > Ever. > > if you do, you risk all kinds of problems, like binNMUs having broken > control files, your package FTBFSing because the script used to generate > the control file no longer functions, and similar things. > > Building debian/control in an automated fashion is fine, but it must not > be done as part of any regular "dpkg-buildpackage" call. This includes > -S, -b, and -B builds (the latter is used by buildd, fwiw). Well, you can update automatically, but you have to make the target fail if it actually changes the control file. (This is roughly what 'linux' and closely associated packages do.) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120621150838.gp2...@decadent.org.uk
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On Sun, Jun 17, 2012 at 02:00:04PM +0200, Joachim Breitner wrote: > Hi, > > it seems that my idea is not well received; point taken, and I do like > the alternative about debian/rules creating debian/control in the clean > target. Do. Not. Do. That. Ever. if you do, you risk all kinds of problems, like binNMUs having broken control files, your package FTBFSing because the script used to generate the control file no longer functions, and similar things. Building debian/control in an automated fashion is fine, but it must not be done as part of any regular "dpkg-buildpackage" call. This includes -S, -b, and -B builds (the latter is used by buildd, fwiw). -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a signature.asc Description: Digital signature
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On Thu, Jun 14, 2012 at 11:04:00AM +0200, Joachim Breitner wrote: > Hi Bernd, > > Am Donnerstag, den 14.06.2012, 10:32 +0200 schrieb Bernd Zeimetz: > > > I would like to see more flexibility in dpkg-source as to where the > > > effective build depends come from. My use case are (as you might guess) > > > Haskell packages. If you look at > > > http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc > > > you see it has a very long list of build dependencies. If you’d compare > > > that to > > > http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal > > > you’d see that the process of creating the build dependencies is a > > > mostly mechanical process and doing that manually is a waste of human > > > developer time and a source for mistakes (which lead to FTBFSes and > > > hence more waste in buildd and buildd admin time). > > > > Other peopel solve this by having a debian/control.in file and having > > - a debian/control target in debian/rules > > - having the clean target depend on debian/control. > > > > I don't think that your case is special enough to add yet an extra > > option to dpkg-source. I have two packages where I'm changing much more > > than the build-dependencies automatically, for example. > > I am aware of approaches using debian/control.in, but I was under the > impression that during the build, debian/control must not be changed and > hence this always requires manual interaction. Yes, and the reason for this is that we don't want accidental build-depends changes by builds on buildd hosts. Your proposed change would violate that. It's fine to use the control.in approach provided it doesn't get done in an automatic build. Just make sure you have a separate debian/rules target which regenerates debian/control when called manually and explicitly, and you should be fine. Then building your package's maintainer upload just involves "debian/rules " followed by a dpkg-buildpackage as usual. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120621072845.gl21...@grep.be
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On Sun, Jun 17, 2012 at 01:39:05PM +0200, Goswin von Brederlow wrote: > I think that the sources-subvars target must function without any > Build-Depends-(Indep) installed because otherwise: Just as an aside, we now have Build-Depends-Arch in addition to Build-Depends-Indep. This means that Build-Depends can be restricted to the common subset needed for packing sources but not those needed for arch-all or arch-any building. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120618121014.ge30...@codelibre.net
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
Le 17/06/2012 14:00, Joachim Breitner a écrit : > Hi, > > it seems that my idea is not well received; point taken, and I do like > the alternative about debian/rules creating debian/control in the clean > target. Modifying debian/control within the clean target of debian/rules would lead to lots of problems already cited (build-depends must be known and correct just after downloading the sources). However, you can implement a 'rules' called in the clean target that check (and perhaps fails) if the current build-depends are wrong (and if it proposes the good one, the fix will be quick when building the package initially). Something similar to what is done for symbols for shared libraries... Regards, Vincent > Nevertheless :-) -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fde3f62.9040...@free.fr
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
Hi, it seems that my idea is not well received; point taken, and I do like the alternative about debian/rules creating debian/control in the clean target. Nevertheless :-) Am Sonntag, den 17.06.2012, 13:39 +0200 schrieb Goswin von Brederlow: > I think that the sources-subvars target must function without any > Build-Depends-(Indep) installed because otherwise: > > - Checking out the source from RCS or downloading the source leaves the > source without full Build-Depends. Getting it from source gives you the .dsc file, so you do have the information. Getting it from RCS; well, that is not an official way for Debian to distribute sources so it is up to the maintainers what comfort level they’d provide. > - Without Build-Depends the source can not be build. > - Without build the sources-subvars can't be generated. > > and you are stuck in a vicious circle. Not so vicious if the missing build dependencies are obvious from possible error messages: If the build process complains about haskell library foo missing, you know you have to install libghc-foo-dev. > Similar for a debian/control target in debian/rules. Although there you > at least have the old Build-Depends to get you started. Not if you follow the rule that no auto-generated file should live in the VCS. As above, this is up to the maintainers to decide; cleanliness of the repo vs. comfort for the check-outer. > Overall I'm not sure the substvars would be better than a debian/control > target. I find generating debian/control somewhat of an hack (as it would be a hack go generate it when creating binary dependencies), but not a bad hack, hence I’m not reopening the bug. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
Joachim Breitner writes: > Hi, > > Am Donnerstag, den 14.06.2012, 11:10 +0200 schrieb Bernd Zeimetz: >> > The only problem I see with this is that if the build dependencies can >> > only be calculated after a full build, building source and binaries >> > requires two builds (and a third one if debuild -tc is used). (Maybe >> > less if debian/rules tracks the dependency of debian/control on *.cabal, >> > but Iâm not sure how reliable this is in the when packing and unpacking >> > the sources.) >> >> Not knowing the build-dependencies before building the packjage >> sounds... WRONG. Whatever you do to figure them out, please do it before >> uploadfing it and trying to do this on a buildd :\ > > thatâs not what I am saying I would (let my mycomputer) figure them out > before uploading, as they would appear in the .dsc file. I was assuming > the buildds use the information in the .dsc files to install the build > dependencies, but if I read Julienâs mail correctly, this is not the > case, so my approach would indeed fail. > > Greetings, > Joachim I think that the sources-subvars target must function without any Build-Depends-(Indep) installed because otherwise: - Checking out the source from RCS or downloading the source leaves the source without full Build-Depends. - Without Build-Depends the source can not be build. - Without build the sources-subvars can't be generated. and you are stuck in a vicious circle. Similar for a debian/control target in debian/rules. Although there you at least have the old Build-Depends to get you started. Overall I'm not sure the substvars would be better than a debian/control target. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d34y5fs6.fsf@frosties.localnet
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On 12-06-14 at 11:13am, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 14.06.2012, 11:10 +0200 schrieb Bernd Zeimetz: > > > The only problem I see with this is that if the build dependencies > > > can only be calculated after a full build, building source and > > > binaries requires two builds (and a third one if debuild -tc is > > > used). (Maybe less if debian/rules tracks the dependency of > > > debian/control on *.cabal, but I’m not sure how reliable this is > > > in the when packing and unpacking the sources.) > > > > Not knowing the build-dependencies before building the packjage > > sounds... WRONG. Whatever you do to figure them out, please do it > > before uploadfing it and trying to do this on a buildd :\ > > that’s not what I am saying I would (let my mycomputer) figure them > out before uploading, as they would appear in the .dsc file. I was > assuming the buildds use the information in the .dsc files to install > the build dependencies, but if I read Julien’s mail correctly, this is > not the case, so my approach would indeed fail. Maybe buildds ignore debian/control and instead trust .dsc for needed build-dependencies, but if so that's an implementation detail. Debian Policy describes that if any build-dependencies are declared in debian/control they must be complete. So as I understand it, your suggested change need (at least) a change of Debian Policy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
Hi, Am Donnerstag, den 14.06.2012, 11:10 +0200 schrieb Bernd Zeimetz: > > The only problem I see with this is that if the build dependencies can > > only be calculated after a full build, building source and binaries > > requires two builds (and a third one if debuild -tc is used). (Maybe > > less if debian/rules tracks the dependency of debian/control on *.cabal, > > but I’m not sure how reliable this is in the when packing and unpacking > > the sources.) > > Not knowing the build-dependencies before building the packjage > sounds... WRONG. Whatever you do to figure them out, please do it before > uploadfing it and trying to do this on a buildd :\ that’s not what I am saying I would (let my mycomputer) figure them out before uploading, as they would appear in the .dsc file. I was assuming the buildds use the information in the .dsc files to install the build dependencies, but if I read Julien’s mail correctly, this is not the case, so my approach would indeed fail. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On 06/14/2012 11:04 AM, Joachim Breitner wrote: > Hi Bernd, > > Am Donnerstag, den 14.06.2012, 10:32 +0200 schrieb Bernd Zeimetz: >>> I would like to see more flexibility in dpkg-source as to where the >>> effective build depends come from. My use case are (as you might guess) >>> Haskell packages. If you look at >>> http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc >>> you see it has a very long list of build dependencies. If you’d compare >>> that to >>> http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal >>> you’d see that the process of creating the build dependencies is a >>> mostly mechanical process and doing that manually is a waste of human >>> developer time and a source for mistakes (which lead to FTBFSes and >>> hence more waste in buildd and buildd admin time). >> >> Other peopel solve this by having a debian/control.in file and having >> - a debian/control target in debian/rules >> - having the clean target depend on debian/control. >> >> I don't think that your case is special enough to add yet an extra >> option to dpkg-source. I have two packages where I'm changing much more >> than the build-dependencies automatically, for example. > > I am aware of approaches using debian/control.in, but I was under the > impression that during the build, debian/control must not be changed and > hence this always requires manual interaction. If Updating > debian/control in the clean target, this is a large step in the right > direction. Well, debian/control is not modified at build time anymore. It is created when *you* build the package before uploading it and should not be modified afterwards. > The only problem I see with this is that if the build dependencies can > only be calculated after a full build, building source and binaries > requires two builds (and a third one if debuild -tc is used). (Maybe > less if debian/rules tracks the dependency of debian/control on *.cabal, > but I’m not sure how reliable this is in the when packing and unpacking > the sources.) Not knowing the build-dependencies before building the packjage sounds... WRONG. Whatever you do to figure them out, please do it before uploadfing it and trying to do this on a buildd :\ -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd9aa93.1000...@bzed.de
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
Hi Bernd, Am Donnerstag, den 14.06.2012, 10:32 +0200 schrieb Bernd Zeimetz: > > I would like to see more flexibility in dpkg-source as to where the > > effective build depends come from. My use case are (as you might guess) > > Haskell packages. If you look at > > http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc > > you see it has a very long list of build dependencies. If you’d compare > > that to > > http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal > > you’d see that the process of creating the build dependencies is a > > mostly mechanical process and doing that manually is a waste of human > > developer time and a source for mistakes (which lead to FTBFSes and > > hence more waste in buildd and buildd admin time). > > Other peopel solve this by having a debian/control.in file and having > - a debian/control target in debian/rules > - having the clean target depend on debian/control. > > I don't think that your case is special enough to add yet an extra > option to dpkg-source. I have two packages where I'm changing much more > than the build-dependencies automatically, for example. I am aware of approaches using debian/control.in, but I was under the impression that during the build, debian/control must not be changed and hence this always requires manual interaction. If Updating debian/control in the clean target, this is a large step in the right direction. The only problem I see with this is that if the build dependencies can only be calculated after a full build, building source and binaries requires two builds (and a third one if debuild -tc is used). (Maybe less if debian/rules tracks the dependency of debian/control on *.cabal, but I’m not sure how reliable this is in the when packing and unpacking the sources.) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
Hi, > I would like to see more flexibility in dpkg-source as to where the > effective build depends come from. My use case are (as you might guess) > Haskell packages. If you look at > http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc > you see it has a very long list of build dependencies. If you’d compare > that to > http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal > you’d see that the process of creating the build dependencies is a > mostly mechanical process and doing that manually is a waste of human > developer time and a source for mistakes (which lead to FTBFSes and > hence more waste in buildd and buildd admin time). Other peopel solve this by having a debian/control.in file and having - a debian/control target in debian/rules - having the clean target depend on debian/control. I don't think that your case is special enough to add yet an extra option to dpkg-source. I have two packages where I'm changing much more than the build-dependencies automatically, for example. Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd9a18c.6070...@bzed.de
Bug#677474: Substvars for Build-Depends in the .dsc file
Package: dpkg-dev Version: 1.16.4.2 Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Dear developers, currently a Debian source package specifies its build dependencies in debian/control; this information gets copied by dpkg-source to the .dsc file. From there it reaches the Source file which is taken into account by our infrastructure, e.g. the build daemons and tools like apt-get build-dep. Therefore, the data in .dsc is the effective copy. I would like to see more flexibility in dpkg-source as to where the effective build depends come from. My use case are (as you might guess) Haskell packages. If you look at http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc you see it has a very long list of build dependencies. If you’d compare that to http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal you’d see that the process of creating the build dependencies is a mostly mechanical process and doing that manually is a waste of human developer time and a source for mistakes (which lead to FTBFSes and hence more waste in buildd and buildd admin time). For binary dependencies, thia issue is solved already: Using substvars we leave it to the build process to figure out the correct dependencies. This has worked great so far. I would like to be able to do the same for build dependencies. Here is my suggestion: dpkg-source already supports substvars. What needs to be added: * A dpkg-source option to enable all this, say --enable-control-substvars (meant to go to debian/source/options) * A way to pass the -T option to dpkg-source in debian/source/options (currently not possible, although this is not clearly documented) * When --enable-control-substvars option is enabled, dpkg-source will call "debian/rules source-substvars" after "debian/rules clean" and after creating the debian.tar.gz files, but before creating the .dsc file¹ * When creating the .dsc file, substvars specified in the file specified in -T may be used in Build-Depends and related fields. One downside is that dpkg-source cannot check the build dependencies completely when calling debian/source clean, as it does now, but can only check those that are given directly in debian/rules; at this stage it should just ignore any substvars. Comments? Thanks, Joachim ¹ Why at this stage? Calculating the precise build dependencies might involve building the package. Doing it here allows this build to also be used for creating the binaries, when doing a regular dpkg-buildpackage build. -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
