Your message dated Thu, 13 Oct 2022 23:17:10 +0200
with message-id <[email protected]>
and subject line Re: Bug#677474: Substvars for Build-Depends in the .dsc file
has caused the Debian Bug report #677474,
regarding dpkg-dev: support substvars in Build-Depends
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
677474: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677474
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.16.4.2
Severity: wishlist
X-Debbugs-CC: [email protected]
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
[email protected] | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: [email protected] | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
On Thu, 2012-06-14 at 17:01:37 +0200, Guillem Jover wrote:
> tag 677474 wontfix
> thanks
> Sorry, but this is not going to happen, the fact that these source
> handling programs do not automatically honour substvars is on purpose.
> It's the same principle as in #5210 and friends. Tagging accordingly.
Some time ago I added an entry in the dpkg FAQ
<https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_substvars_not_effective_.28by_default.29_on_parts_of_debian.2Fcontrol.3F>,
so I don't see much point in keeping this open wontfix bug. Thus
closing.
Thanks,
Guillem
--- End Message ---
