Your message dated Fri, 13 Sep 2024 06:32:06 +0200
with message-id <[email protected]>
and subject line Re: Bug#1081544: /usr/bin/dpkg-buildpackage: debian does not
have an option to version each package in a control file uniquely
has caused the Debian Bug report #1081544,
regarding /usr/bin/dpkg-buildpackage: debian does not have an option to version
each package in a control file uniquely
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.)
--
1081544: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081544
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.22.6ubuntu6.1
Severity: normal
File: /usr/bin/dpkg-buildpackage
X-Debbugs-Cc: [email protected]
Dear Maintainer,
* What led up to the situation?
- 1 source, 2 different versions. I.E. compute-runtime
* What exactly did you do (or not do) that was effective (or
ineffective)?
- Talk to Timo
* What was the outcome of this action?
- While rpm based distro's have an option in 1 spec file to define
each version of a package, debian does not.
- Requesting this feature to be added to debian packaging.
-- Package-specific info:
-- System Information:
Debian Release: trixie/sid
APT prefers noble-updates
APT policy: (500, 'noble-updates'), (500, 'noble-security'), (500, 'noble'),
(100, 'noble-backports')
Architecture: amd64 (x86_64)
Kernel: Linux 6.8.0-44-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dpkg-dev depends on:
ii binutils 2.42-4ubuntu2
ii bzip2 1.0.8-5.1build0.1
ii libdpkg-perl 1.22.6ubuntu6.1
ii lto-disabled-list 47
ii make 4.3-4.1build2
ii patch 2.7.6-7build3
ii perl 5.38.2-3.2build2
ii tar 1.35+dfsg-3build1
ii xz-utils 5.6.1+really5.4.5-1build0.1
Versions of packages dpkg-dev recommends:
ii build-essential 12.10ubuntu1
ii fakeroot 1.33-1
ii gcc [c-compiler] 4:13.2.0-7ubuntu1
ii gcc-11 [c-compiler] 11.4.0-9ubuntu1
ii gcc-12 [c-compiler] 12.3.0-17ubuntu1
ii gcc-13 [c-compiler] 13.2.0-23ubuntu4
ii gcc-9 [c-compiler] 9.5.0-6ubuntu2
ii gnupg 2.4.4-2ubuntu17
ii gpgv 2.4.4-2ubuntu17
ii libalgorithm-merge-perl 0.08-5
Versions of packages dpkg-dev suggests:
pn debian-keyring <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
On Thu, 2024-09-12 at 08:39:17 -0700, Pavel Androniychuk wrote:
> Package: dpkg-dev
> Version: 1.22.6ubuntu6.1
> Severity: normal
> File: /usr/bin/dpkg-buildpackage
> X-Debbugs-Cc: [email protected]
> * What led up to the situation?
> - 1 source, 2 different versions. I.E. compute-runtime
To be pedantic, I'd say a source package cannot have two source
package versions. It might have sub-versions, say because it embeds
multiple other projects, because it has absorbed them, or because
different components within are versioned differently, but when an
upstream releases a tarball, then that can only have a single version
(even if it ends up being the combination of the multiple versions
within).
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> - Talk to Timo
I assume Timo here is the intel-compute-runtime maintainer. Who
recommended the following?
> * What was the outcome of this action?
> - While rpm based distro's have an option in 1 spec file to define
> each version of a package, debian does not.
> - Requesting this feature to be added to debian packaging.
As Blair has mentioned, dpkg supports specifying different versions
for each binary package, even different to their source package. So I
don't see anything to fix there. Thus closing.
Thanks,
Guillem
--- End Message ---
