Your message dated Thu, 13 Oct 2022 23:41:24 +0200
with message-id <Y0iGBBjJ/ddlo...@thunder.hadrons.org>
and subject line Re: Bug#5210: dpkg-source complains on substitution variables
has caused the Debian Bug report #5210,
regarding dpkg-gencontrol: Support substvars in names of binary packages
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 ow...@bugs.debian.org
immediately.)
--
5210: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5210
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.9.21
Severity: wishlist
If dpkg-genchanges finds discreprencies between the control file and the
files list file, it should use the latter for generating the Binary:
field, and not the former.
I have a modules package, which means that it generates a package named
poldhu-$(kvers}. I have that in my control file:
joey@satin:~/lib/kernel/modules/poldhu-0.2.12>grep Package: debian/control
Package: poldhu-${kvers}
I manage quite cleanly (rules file attached) to make dpkg-gencontrol
stubstitute in the kernel version for ${kvers} in the generated
DEBIAN/control file. Likewise it generates a correct debian/files:
joey@satin:~/lib/kernel/modules/poldhu-0.2.12>cat debian/files
poldhu-2.4.18_0.2.12-7_i386.deb admin extra
Unlike most kernel module packages, I am *not* running sed on the control file;
that is what dpkg-gencontrol is for. And it works fine. But.
The problem comes when dpkg-genchanges is run:
joey@satin:~/lib/kernel/modules/poldhu-0.2.12>dpkg-genchanges
dpkg-genchanges: warning: package poldhu-${kvers} in control file but not in
files list
dpkg-genchanges: warning: package poldhu-${kvers} in control file but not in
files list
dpkg-genchanges: warning: package poldhu-${kvers} in control file but not in
files list
dpkg-genchanges: warning: package poldhu-${kvers} in control file but not in
files list
dpkg-genchanges: warning: package poldhu-${kvers} in control file but not in
files list
dpkg-genchanges: warning: package poldhu-2.4.18 listed in files list but not in
control info
dpkg-genchanges: warning: package poldhu-2.4.18 listed in files list but not in
control info
dpkg-genchanges: not including original source code in upload
Format: 1.7
Date: Thu, 20 Jun 2002 14:50:01 -0400
Source: poldhu
Binary: poldhu-${kvers}
Architecture: source
Version: 0.2.12-7
Distribution: unstable
Urgency: low
Maintainer: Joey Hess <jo...@debian.org>
Changed-By: Joey Hess <jo...@debian.org>
Changes:
poldhu (0.2.12-7) unstable; urgency=low
.
* Corrected building w/o pcmcia-cs available.
Files:
daf7ccb36bb27bd7f427f9083398ef76 580 admin extra poldhu_0.2.12-7.dsc
0be5dc65552859085b0b5fad08169b49 3281 admin extra poldhu_0.2.12-7.diff.gz
5e0ca563bba1962a6742db4e97bfd4b4 21128 admin extra
poldhu-2.4.18_0.2.12-7_i386.deb
Notice the broken Binary: field. I'm sure this would never pass by incoming.
It seems to me that dpkg-genchanges knows what packages are in the files
list file, so why not just use that list of packages for the Binary: line?
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux satin 2.4.18 #1 Wed Jun 19 23:07:31 EDT 2002 i586
Locale: LANG=C, LC_CTYPE=C
Versions of packages dpkg-dev depends on:
ii binutils 2.12.90.0.9-1 The GNU assembler, linker and bina
ii cpio 2.4.2.91-2 GNU cpio -- a program to manage ar
ii make 3.79.1-14 The GNU version of the "make" util
ii patch 2.5.4-11 Apply a diff file to an original
ii perl [perl5] 5.6.1-7 Larry Wall's Practical Extraction
ii perl-modules 5.6.1-7 Core Perl modules.
#!/usr/bin/make -f
#
# This rules file is invoked in three different ways. Either I am building a
# source-only release of the package to upload to the debian archive, or
# the package is being built as a kernel module by make-kpkg, or apt-src.
ifdef APT_SRC_BUILD
# Get info from apt-src about where the kernel source is, and what version
# it is. These variables are otherwise set by make-kpkg.
KVERS=$(shell apt-src version 'kernel-source.*')
KSRC=$(shell apt-src location 'kernel-source.*')
endif
ifdef KVERS
# Make debhelper build the package by the right name. Also, make it use
# debian/postinst, etc as the files for the package it builds, instead of
# using debian/poldhu-$(KVERS).postinst.
PACKAGE=poldhu-$(KVERS)
export DH_OPTIONS=-p$(PACKAGE) --mainpackage=$(PACKAGE)
endif
# If the module is being built and the kernel is compiled to not use
# the in-kernel pcmcia drivers, the module needs to be built against the
# pcmcia-cs source tree. For now, if apt-src knows about it, use it..
PCMCIA_CS=$(shell apt-src location pcmcia-\(cs\|source\))
ifneq (,$(PCMCIA_CS))
export DEBIAN_CFLAGS=-D__IN_PCMCIA_PACKAGE__ -I$(PCMCIA_CS)/include
endif
# Work out where the deb file should go. For make-kpkg, it needs to go
# below the kernel source; otherwise it can do in the regular place.
ifdef KMAINT # set my make-kpkg
DEST=$(KSRC)/..
else
DEST=..
endif
build:
ifdef KVERS
dh_testdir
./Configure -n --kernel=$(KSRC) --target=`pwd`/debian/$(PACKAGE)
$(MAKE) all
endif
clean:
dh_testdir
dh_testroot
-$(MAKE) clean
dh_clean
binary-arch: build
ifdef KVERS
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs etc/pcmcia
$(MAKE) install
dh_installchangelogs
dh_installdocs README TODO
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_installdeb
dh_gencontrol -- -Vkvers=$(KVERS)
dh_md5sums
dh_builddeb --destdir=$(DEST)
else
# Have to stub in a debian/files here to keep dpkg-genchanges happy.
touch debian/files
endif
binary-indep:
binary: binary-indep binary-arch
# These targets are used by make-kpkg. Just stub in to the real targets.
kdist_config:
kdist_build: build
kdist_clean: clean
kdist_image: binary
.PHONY: build clean binary-indep binary-arch binary
.PHONY: kdist_config kdist_build kdist_clean kdist_image
--- End Message ---
--- Begin Message ---
Hi!
On Fri, 1996-11-01 at 09:14:57 +1100, Mr Stuart Lamble wrote:
> Package: dpkg
> Version: 1.4.0.2
> When I was building up libelf0, I tried using ${MAJOR} in debian/control:
>
> Package: libelf${MAJOR}
> ...
> Package: libelf${MAJOR}-dev
>
> in an attempt to not have to edit the control file when libelf 1.0.0 comes
> out. (yeah, I'm lazy. :) dpkg-source barfs on this, despite having setup
> substvars properly, claiming that the package has two conflicting names,
> libelf0 and libelf${MAJOR}.
>
> I worked around it by changing the ${MAJOR}s to 0, but as I read the manual,
> it should know how to use substvars to do the required job. 'Course, I could
> be showing off my ignorance here. :)
This has been marked as wontfix for a long time, and that's not going
to change (at least in the foreseeable future). Some time ago I added an
entry covering this to the dpkg FAQ at
<https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_substvars_not_effective_.28by_default.29_on_parts_of_debian.2Fcontrol.3F>,
so there's no point in keeping this wontfix bug open, thus closing it
now.
Thanks,
Guillem
--- End Message ---
