Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Debian Policy version 3.9.4 adds support for the Built-Using field. This field can be different on each build run and so is analagous to the shlibs fields added via dpkg-shlibdeps. The differences are: 1.) we are talking about static libraries rather than shared libraries 2.) we need the source package rather than the binary package.
Hi! Even if it might seem so, it's really not like those substvars, because the values to put into Built-Using cannot be easily computed automatically (if at all). See previous discussion in #653575. Which cannot be reliably inferred from stripped binaries, in contrast to shared libraries. Which can already be easily retrieved through the dpkg-query source:Package and source:Version virtual fields. As such, I'm going to be closing this request if there's no additional feedback proposing a workable and elegant solution to this. thanks, guillem
Guillem, Thanks for responing. I think I can come up with a proposed mechanism. I'd be grateful if you'd allow me some time as it does not need to be in Debian before Wheezy is released.
Sure thing, no hurry, it was more to do to with keeping the bts under control and clean than anything related to the wheezy release. regards, guillem
Problem
=======
Debian Policy 3.9.4 (section 7.8) mandates the use of a "Built-Using"
field listing source packages and their versions. Typically this will be
needed where packages are statically linked against libraries, in which
case the source package containing the library must be indicated. There
may be other cases where source code is
incorporated into a binary package. Techincally the shell script
fragments incorporated into Debian maintance scripts by debhelper may
fall into this category, although this may not be needed to solve the
original issue.
What this is like
=================
This problem is a bit like that solved by dh_shlibdeps and
dpkg-shlibdeps. The dependency can only actually be calcuated at build
time. So without support from the build system the Debian Policy is not
implementable.
Proposed solution
=================
We need a tool, dh_builtusing, which is driven by files of the form
"debian/*.builtusing". These files are simply lists of files or
directories that the build process depends on which trigger the
requirements for filling the Built-Using clause. dh_builtusing would
resolve these files into the appropriate dependency using
PACKAGE=`dpkg-query -S ${FILE} | cut -d':' -f1`
dpkg-query -f'${Source}\n${Version}\n' -W ${PACKAGE}
and create substvars variables which would complete the information
retrieval.
It looks increasingly likely to me that this is purely a debhelper issue
and dpkg already provides all that is required.
Further automation
==================
The typical use case my be expected to be a package using autoconf,
libtools, pkg-config or something similar. I speculate that hooks could
be added to those tools to create builtusing files.
Nicholas Bamber wrote: For code that is licensed like so? Redistribution and use in source and binary forms, with or without modification, are permitted under any circumstances. No warranty. Give me a break.
Joey, Sorry yes I did not mean to imply that there was a copyright issue with the inclusion of debhelper fragments in maintenance scripts, just an example of techincally it might happen. The policy explicitly mentions "incorporating source code". I used the word "techincally" and added the rider "although this may not be needed to solve the original issue.". I only meant it as an example of how source code copying could trigger it. I don't think the automated part can take a view on the copyright issues. For a more copyright-heavy example, see how "handlersocket" is built using mysql-source-5.5. I didn't want to use that example partly because I am unhappy with that example and I would not want to advocate it. I really just wanted to know what the plans were for supporting the "Built-USing" clause. So far most people I have spoken to seem unaware that there is an issue which made me feel I had to put a proposal together.
Hi,
Nicholas Bamber wrote:
Based on <http://bugs.debian.org/688251>, it seems there is some
belief that the policy wording here is broken. I'm inclined to agree
with that --- it would be lovely to have a table of what binary
packages incorporate code from what source packages to help with
binnmus when there is an important fix, but that would be a pain to
maintain and wasn't the purpose of the Built-Using field that caused
a consensus to form around adding it to policy.
For reference, the current wording is:
Some binary packages incorporate parts of other packages when
built but do not have to depend on those packages. Examples
include linking with static libraries or incorporating source
code from another package during the build. In this case, the
source packages of those other packages are a required part of
the complete source (the binary package is not reproducible
without them).
A Built-Using field must list the corresponding source package
for any such binary package incorporated during the build
I suspect some mention of license requirements or a threshold of
substantial amounts of code copied would help.
[...]
Yes, that is a more typical case where Built-Using is intended to be
useful.
In pseudocode, something like this should work:
built_using=
for package in Build-Depends:
if package name does not match the pattern *-source-*:
continue
pkgname=$(dpkg-query -W -f='${source:Package}' $package)
pkgver=$(dpkg-query -W -f='${source:Version}' $package)
built_using=${built_using+$built_using, }$pkgname" (= $pkgver)"
...
dpkg-genchanges -Vbuilddeps:Built-Using="$built_using" ...
This mechanism should be very useful for some use cases such as safely
adding cross-compilers (which build-depend and incorporate code from
gcc-source) to the archive.
Hoping that clarifies,
Jonathan
* Guillem Jover <guillem@debian.org>, 2012-09-28, 22:55:
Let's introduce a new class of standard substitution variables, one for
every binary package, expanding to "<source> (= <version>)". Then user
could decide which of them use in the Built-Using field. E.g.:
Built-Using: ${foocc-source:Source}, ${libbaz-dev:Source}
Hi!
Yeah, I guess that would be an improvement over having to compute the
value in debian/rules and pass it over to dpkg-gencontrol, certainly
more maintenable.
Although using the package name at the front seems dangerous as it
could stomp over other substvar variables. And :Source seems too generic
for this case which is pretty specific. Probably better something
like ${Built-Using:pkgname} or ${srcdep:pkgname} (to match shlibs),
although the former is pretty long and repetitive with the field name,
maybe better with just ${B:pkgname} mimicking the ${F:fieldname} magic
substvars. If the package is not installed then we should at least
warn, or maybe even error out.
From an implementation PoV it's a bit ugly as it needs to be
instantiated at substitution time, as pre-loading all packages in the
status file as substvars would be too much. I've started coding this
just to see how it ends up, and will consider inclusion for 1.17.x if
it's not too onerous.
thanks,
guillem
Hi everyone,
Build-Using: ${bar-source:Source} | ${baz-source:Source} ?
It becomes interesting if bar-source and baz-source are co-installable :)
If this use case isn't going to be supported, I think that whatever dpkg-foo
is going to generate the substitutions should check for them (b-u package
has alternatives) and possibly abort. Unless one wants to delegate that to
lintian...
How about BU (short for Built-Using) or BS (short for Binary's Source)?
I find a lone B kind of confusing.
Cheers,
Hello. I have written a tool inspired by this bug report. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035888 A full description is available at https://salsa.debian.org/debian/dh-builtusing/-/blob/master/dh_builtusing.pod This is a proof of concept, any suggestion or critic is welcome (especially before anyone starts depending on it :-). A separate debhelper tool avoids extending the dpkg interface. It should be easier to maintain and document. The price is some redundancy. The tool parses debian/control twice, via Dh_Lib and Dpkg perl modules.
Hello. I took the absence of answer to my messages here and the ITP as an agreement that an external tool, if somewhat redundant, is preferable to a change in the dpkg-gencontrol public interface, where any change has wide repercussions. So here is the prototype: https://manpages.debian.org/unstable/dh-builtusing/dh_builtusing.1.en.html Do the submitter and maintainers agree to close this bug?
Hello. Dh-builtusing is available in unstable.