Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Package: dpkg-dev Followup-For: Bug #689062 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?
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Hi everyone,
On Sunday 14 October 2012 20:06:19 Guillem Jover wrote:
On Sun, 2012-10-14 at 23:12:14 +0200, Jakub Wilk wrote:
I'd like to propose the following solution:
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}
What about ORed build-dependencies?
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...
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.
How about BU (short for Built-Using) or BS (short for Binary's Source)?
I find a lone B kind of confusing.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
* Guillem Jover guil...@debian.org, 2012-09-28, 22:55:
I'm going to be closing this request if there's no additional feedback
proposing a workable and elegant solution to this.
I'd like to propose the following solution:
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}
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Hi!
On Sun, 2012-10-14 at 23:12:14 +0200, Jakub Wilk wrote:
* Guillem Jover guil...@debian.org, 2012-09-28, 22:55:
I'm going to be closing this request if there's no additional
feedback proposing a workable and elegant solution to this.
I'd like to propose the following solution:
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}
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
On 28/09/12 23:46, Guillem Jover wrote:
On Fri, 2012-09-28 at 22:50:10 +0100, Nicholas Bamber wrote:
On 28/09/12 21:55, Guillem Jover wrote:
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 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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Nicholas Bamber wrote: Techincally the shell script fragments incorporated into Debian maintance scripts by debhelper may fall into this category 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. -- see shy jo signature.asc Description: Digital signature
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/09/12 16:36, Joey Hess wrote: Nicholas Bamber wrote: Techincally the shell script fragments incorporated into Debian maintance scripts by debhelper may fall into this category 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQZyErAAoJELbE2bY7/+c8EygQAOM8dDSqIlIhIawX2PqUSPYg 0PEzSDozlXCU0vu3fVcGwm+bEjCcLGCuweP2o9d4zvTutRo9XUqRHp3kvquBkGBH PJG5jqUGKIB2WoAK3XjvBCKbZ/k4Vod/IqVkQGuhPvRod+aOGcDCZdiwipJ7JMye 7TdwpzZ89H0K0I/j4YMogT6JSqJSWSskWlETn1Zw92g6xxDxBg6CgkiM7+U6GM49 8SKI03Za+cQvZrPFJULmrI0XRD8N4wLRLODgmnBFAyLePQS/C7bXt/LhZjIckgqY /qu1djwTmYzqVIEFLvPZuUZVndgBKG4G7yDuKsjnBlAKwMCoh1BSfOxg486hje6n 0J892eKg/hzXIEdGoyH8+sEqnS5pxIVb9oB1dnOp+wk7R2fc9eVsLUjlYxlyMFj2 mlRWvI84R+wsAjCzQz9kwLXCP8gcDO++DI7RUDO6MqGd/jjV+R923UJehdCICycC 6N/7n/pPsDQAa1yTKARryHMZkiv0m3v8YIrfr4JwOOCq5yHGRhUhgt1y+nl/XPaV O7Mj+nLNYqgSJjwVIqKpGYd7ZOEIjvNi2d//d4vdbNoOq46Wo+IAH6t7ZBwfZif9 zg7WtU3Y8K/3LgMXLa47NUMSxbPtKHK/zyJte3tIupyEFU1Zw2hzfy1QKVOpLM9s mWx2wcLcebZpjOzKWLv5 =yfMB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Package: dpkg-dev Version: 1.16.8 Severity: normal 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. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii base-files6.11 ii binutils 2.22-7.1 ii bzip2 1.0.6-4 ii libdpkg-perl 1.16.8 ii make 3.81-8.2 ii patch 2.6.1-3 ii xz-utils 5.1.1alpha+20120614-1 Versions of packages dpkg-dev recommends: ii build-essential 11.5 ii clang [c-compiler] 3.1-8 ii fakeroot 1.18.4-2 ii gcc [c-compiler] 4:4.7.2-1 ii gcc-4.4 [c-compiler] 4.4.7-3 ii gcc-4.5 [c-compiler] 4.5.4-1 ii gcc-4.6 [c-compiler] 4.6.3-10 ii gcc-4.7 [c-compiler] 4.7.2-2 ii gnupg1.4.12-4+b1 ii gpgv 1.4.12-4+b1 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2012.06.01 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Control: severity -1 wishlist Hi! On Fri, 2012-09-28 at 20:58:13 +0100, Nicholas Bamber wrote: Package: dpkg-dev Version: 1.16.8 Severity: normal 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. 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. The differences are: 1.) we are talking about static libraries rather than shared libraries Which cannot be reliably inferred from stripped binaries, in contrast to shared libraries. 2.) we need the source package rather than the binary package. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
On 28/09/12 21:55, Guillem Jover wrote: Control: severity -1 wishlist Hi! On Fri, 2012-09-28 at 20:58:13 +0100, Nicholas Bamber wrote: Package: dpkg-dev Version: 1.16.8 Severity: normal 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. 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. The differences are: 1.) we are talking about static libraries rather than shared libraries Which cannot be reliably inferred from stripped binaries, in contrast to shared libraries. 2.) we need the source package rather than the binary package. 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
On Fri, 2012-09-28 at 22:50:10 +0100, Nicholas Bamber wrote: On 28/09/12 21:55, Guillem Jover wrote: 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 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
