[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1106402: marked as done (dpkg-source, native source package format with non-native version)

Your message dated Mon, 6 Oct 2025 11:34:51 +0200
with message-id <90dfbea2-4458-4816-902e-ded8ea17f1d4@mail.gaussglocke.de>
and subject line Re: Bug#1106402: dpkg-source, native source package format with  non-native version
has caused the Debian Bug report #1106402,
regarding dpkg-source, native source package format with non-native version
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 owner@bugs.debian.org
immediately.)


-- 
1106402: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106402
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tech-ctte
Control: tags 737634 patch
Control: block 737634 by -1

Hi.

I would like the Technical Committee to explicitly use its power in
Constitution 6.1 (1) "Decide on any matter of technical policy"
to decide that:

  dpkg-source should be able to build "3.0 (native)" source packages
  with a non-native version number.

Note that this does not require a supermajority - a simple majority
will do, since this is "the behaviour of non-experimental package
building tools".

A 10-year-old patch is available to implement the change.

I would also ideally like the TC to explicitly give advice that they
think this change is appropriate for trixie.


Scope
-----

We are talking here precisely about the behaviour of dpkg-source
when the version number has a hyphen, and the source format is
"3,0 (native)".

Currently dpkg-source -b it fails with an error.

Note ethat we are not debating (any longer) whether "3.0 (native)"
packages with a non-native version number are incorrect.  That was
settled in 2022 by TC decison: the answer is "yes, they are fine".

The remaining problem is simply that dpkg-source still rejects them.


History
-------

In 2014 dpkg-source was changed to reject these source packages at
build time.

Quickly, a bug was filed,
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634

In that bug several people request the previous behaviour be restored
and give practical explanations why they want to do things that way.
There are a variety of use cases presented.

In 2022, the matter was discussed (along with many other things) by
the Technical Committee.  The TC ruling can be found here:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#107

The full discussion (which includes other matters too) is here:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717

The TC decided to agree with us on the substance.  But the wording in
the resolution is unfortuante.  The TC say that there is nothing wrong
with this situation, that dpkg-source rejects.  But they then say only
"We suggest that the wontfix tag on #737634 be reconsidered".

The maintainer did not respond to this TC decision.  Nor did they
respond to a followup message in January 2024.


Current situation
-----------------

The Technical Committee has declared what Debian's technical policy is
in this area.  However, the dpkg-srouce maintainer has failed to
align the software with Debian policy.


As I understand from

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#112

Ubuntu have patched their version of dpkg-source to relax this
restriction.  One consequence is that Ubuntu now contains source
packages that cannot be edited and then rebuild with upstream Debian
tooling.


There is this patch from Adam Conrad:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#102

I haven't tried applying it, but I expect that if it doesn't work, the
fix will be about as simple.

This issue means that I have many packages that are still using 1.0
source format, despite its several important behavioural flaws, when
they could be using 3.0.  It also greatly complicates recommending
good packaging workflows.

So I would like to see this resolved.


I appreciate that the relationship between the dpkg maintainer and the
TC is poor.  But, the TC is the appropriate venue for this decision.
The maintainer has clearly indicated by their non-responses in 2022
and again in 2024 that they don't intend to reconsider this question.

Given that all the technical matters were already discussed
exhaustively in #1007717, I'm hoping that the TC can make a decision
fairly quickly.


Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- End Message ---
--- Begin Message --- 
Hi,
On Thu, 3 Jul 2025 19:04:04 +0100 Matthew Vernon <matthew@debian.org> wrote:
I think that with the pending changes in dpkg, and policy discussion (to make policy match the previous TC resolution) happening on -policy, there is no need for this TC bug to be kept open any more?
Given that there have been no objections, I'm going to close this bug now. Thanks to everyone participating in the discussion. 

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: