Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Thorsten Glaser]

Russ Allbery dixit:

>local-options means that the maintainer sees a very different view of the
>package than any other consumer on the package via the archive.  Not only

Right, but the packaging workflow is the same (and since there is only
one quilt patch, the view other developers have pretty much matches).
It even has a benefit: NMUs can be added as extra quilt patches, and
the maintainer can just commit them.

>is this philosophically a bit weird, it also breaks tools that try to keep
>the repository and maintainer view consistent (such as dgit).  I suspect
>it is therefore not the solution Ian is looking for.

Ah right, there’s that. OK.

Hope the method I’ve suggested helps someone reading the archives anyway,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Russ Allbery]

Thorsten Glaser  writes:
> Ian Jackson dixit:

>> The problem is that `3.0 (quilt)' has both advantages (eg that
>> `nativeness' is declared explicitly) and disadvantages (patches stored

> Not necessarily:

> | $ cat rs/debian/source/local-options
> |single-debian-patch
> | $ cat rs/debian/source/local-patch-header
> |Please review changes against upstream code using SCM,
> |see the Vcs-* tags in debian/control for its location.
> |

> (empty line at the end)

> This allows working with 3.0 (quilt) packages precisely the same way
> (well plus a “git clean -dfx” after building) than with 1.0 packages.

local-options means that the maintainer sees a very different view of the
package than any other consumer on the package via the archive.  Not only
is this philosophically a bit weird, it also breaks tools that try to keep
the repository and maintainer view consistent (such as dgit).  I suspect
it is therefore not the solution Ian is looking for.

-- 
Russ Allbery (r...@debian.org)  

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Thorsten Glaser]

Ian Jackson dixit:

>The problem is that `3.0 (quilt)' has both advantages (eg that
>`nativeness' is declared explicitly) and disadvantages (patches stored

Not necessarily:

| $ cat rs/debian/source/local-options
|single-debian-patch
| $ cat rs/debian/source/local-patch-header
|Please review changes against upstream code using SCM,
|see the Vcs-* tags in debian/control for its location.
|

(empty line at the end)

This allows working with 3.0 (quilt) packages precisely the
same way (well plus a “git clean -dfx” after building) than
with 1.0 packages.

So, while it can be a bit annoying to have to first cut an
origtgz from your repo excluding debian/ (or from a separate
upstream branch) it works very well without tearing down the
native package boundary.

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Felix Lechner]

Hi,

On Fri, Jun 12, 2020 at 3:30 AM Ian Jackson
 wrote:
>
> As for `3.0 (native)', it has one serious disadvantage: dpkg-source
> has been programmed to reject version numbers with a Debian revision.
> If that restriction were relaxed, `3.0 (native)' would be a strictly
> superior drop-in replacement for 1.0-native and I doubt anyone would
> have any objection to phasingt 1.0-native out completely.

What a winning trade! The restriction should be lifted right away.

Kind regards
Felix Lechner

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Ian Jackson]

Felix Lechner writes ("debian-policy: Please permit Debian revisions with 1.0 
native packages"):
> As a Lintian maintainer, I would like to express support for Ian's
> effort to remove restrictions on Debian version strings.
> 
> Unlike Ian, however, I also believe all packages should be converted
> to format 3.0. A package's 'nativeness' is then declared explicitly,
> and does not have to be inferred from the version string.

On 1.0 vs 3.0:

I agree that the nativeness should be declared explicitly.  If there
were a 3.0 format which was strictly superior to 1.0-with-diff then I
would have no objection to deprecating 1.0-with-diff.  But sadly there
isn't.

The problem is that `3.0 (quilt)' has both advantages (eg that
`nativeness' is declared explicitly) and disadvantages (patches stored
in the tree, complex interactions with dpkg-source, cannot handle
packages whose upstream contains a .pc directory, very confusing to
those new to Debian, ...).  Many of these disadvantages are inherent
in the design of `3.0 (quilt)'.  A peruse of the dpkg-source bug list
shows that it's not just me who sees problems with `3.0 (quilt)'.[1]

Whether to choose one set of disadvantages, or another set, should be
a workflow choice for the maintainer.

Obviously it would be possible for there to be a new format of some
kind (maybe something like a `3.0 (diff)') which would address these
issues.  But the dpkg maintainers haven't evidently haven't felt such
a thing to be an appropriate part of their programme to abolish 1.0,
since they haven't provided it in all these years.

As for `3.0 (native)', it has one serious disadvantage: dpkg-source
has been programmed to reject version numbers with a Debian revision.
If that restriction were relaxed, `3.0 (native)' would be a strictly
superior drop-in replacement for 1.0-native and I doubt anyone would
have any objection to phasingt 1.0-native out completely.

Thanks,
Ian.

[1] I do feel I need to say that `3.0 (quilt)' is a massive
improvement over what was being done before its introduction.  I can
quite see why it was designed the way it was.

-- 
Ian JacksonThese 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.

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Ian Jackson]

Jonathan Nieder writes ("Re: debian-policy: Please permit Debian revisions with 
1.0 native packages"):
> Hi,
> 
> Sam Hartman wrote:
> 
> > I think there are at least two cases where this issue comes up and is
> > important, and where using a debian revision without separate upstream
> > tarballs is the right approach:
> >
> > 1) small packages currently maintained by the upstream maintainer where
> > debian revision is incremented for packaging only changes and upstream
> > revision is incremented for upstream versions
> >
> > and
> >
> > 2) Cases typically outside the Debian archive where a git tree is being
> > built as a Debian package especially as part of a CI system and where
> > the effort of tracking upstream tarballs is undesired.
> >
> > 2) is more of an issue for lintian than it is for debian-policy.
> 
> I don't have any strong opinions about this, but I got the impression
> that Ian's motivation is a different case 3):

I agree with both of Sam's motivating scenarios.  But I also agree
with you that I presented a different scenario:

> | Most packages are maintained in git nowadays.  It is usual to have a
> | separate git branch for Debian and upstream work.  In such a situation
> | it makes perfect sense to have an upstream version number which
> | corresponds to an upstream tag.  For packages with a very small (or
> | zero) Debian delta to the upstream files, it makes sense to maintain
> | these git branches using `git merge' rather than as a stack of
> | patches.
> |
> | However, there are serious inherent problems with all of the
> | non-native source formats.  There are many that can occur in git
> | repositories which are not representable in non-native packages.  For
> | example, changes to symlinks.  Worse, one must either choose
> | `3.0 (quilt)' *which involves patch files within the git tree
> | and a great deal of complexity to manage those*; or 1.0-with-diff which
> | has an even more restricted set of things it can represent.

[emphasis added]

> Regardless of what happens to the 1.0 format, shouldn't the non-native
> package formats be improved to handle this?  The "git diff" format,
> which GNU patch has reasonable support for, is able to represent all
> of these kinds of changes, including changes to symlinks.  Tooling for
> handling 3.0 (quilt) packages is reasonably good at generating an
> appropriate single-diff quilt at build time.  To the extent that this
> doesn't work, it seems worth fixing.

Well, maybe.  I agree that some improvement here is warranted, but it
would need a transition plan to avoid uncontrolled adoption of source
package features meaning that source packages unexpectedly cannot be
unpacked on older releases of Debian.

But that does not solve the problem for my scenario.  I wrote:

|  *which involves patch files within the git tree
|   and a great deal of complexity to manage those*

I do not agree with the thrust of your comment that "Tooling for
handling 3.0 (quilt) packages is reasonably good at generating an
appropriate single-diff quilt at build time".  It's true as far as it
goes but doesn't address the key problems, namely that the single
patch ends up inside the tree.

This could be solved by a new `3.0 (diff)' format perhaps.  If and
when that is provided then this one scenario would perhaps be better
handled that way.  But we are not there yet.

The other two scenarios presented by Sam would still remain as reasons
to have a native package with a hyphen in the version number.

Ian.

-- 
Ian JacksonThese 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.

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Bill Allombert]

On Fri, Jun 12, 2020 at 09:09:22AM +, Holger Levsen wrote:
> hi,
> 
> I'm not fully sure if people really intend to change the 1.0 format, but if 
> so,
> I'm against it. If you do it, please call it 1.1 or whatever, but please don't
> change 1.0, too many tools rely on it's decade old behavior.
  
For what it is worth, Debian revisions with 1.0 native package were
allowed for a long time. so this is not a change to the 1.0 format.

> Besides that it's also my opinion that we should get rid off native packages
> completly, though that's yet another discussion. Native packages made sense
> when Debian had little or no downstreams, but...

I believe there are exceptions.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Holger Levsen]

hi,

I'm not fully sure if people really intend to change the 1.0 format, but if so,
I'm against it. If you do it, please call it 1.1 or whatever, but please don't
change 1.0, too many tools rely on it's decade old behavior.

Besides that it's also my opinion that we should get rid off native packages
completly, though that's yet another discussion. Native packages made sense
when Debian had little or no downstreams, but...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Jonathan Nieder]

Hi,

Sam Hartman wrote:

> I think there are at least two cases where this issue comes up and is
> important, and where using a debian revision without separate upstream
> tarballs is the right approach:
>
> 1) small packages currently maintained by the upstream maintainer where
> debian revision is incremented for packaging only changes and upstream
> revision is incremented for upstream versions
>
> and
>
> 2) Cases typically outside the Debian archive where a git tree is being
> built as a Debian package especially as part of a CI system and where
> the effort of tracking upstream tarballs is undesired.
>
> 2) is more of an issue for lintian than it is for debian-policy.

I don't have any strong opinions about this, but I got the impression
that Ian's motivation is a different case 3):

| Most packages are maintained in git nowadays.  It is usual to have a
| separate git branch for Debian and upstream work.  In such a situation
| it makes perfect sense to have an upstream version number which
| corresponds to an upstream tag.  For packages with a very small (or
| zero) Debian delta to the upstream files, it makes sense to maintain
| these git branches using `git merge' rather than as a stack of
| patches.
|
| However, there are serious inherent problems with all of the
| non-native source formats.  There are many that can occur in git
| repositories which are not representable in non-native packages.  For
| example, changes to symlinks.  Worse, one must either choose
| `3.0 (quilt)' which involves patch files within the git tree
| and a great deal of complexity to manage those; or 1.0-with-diff which
| has an even more restricted set of things it can represent.

Regardless of what happens to the 1.0 format, shouldn't the non-native
package formats be improved to handle this?  The "git diff" format,
which GNU patch has reasonable support for, is able to represent all
of these kinds of changes, including changes to symlinks.  Tooling for
handling 3.0 (quilt) packages is reasonably good at generating an
appropriate single-diff quilt at build time.  To the extent that this
doesn't work, it seems worth fixing.

Thanks,
Jonathan

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Sam Hartman]

I strongly agree with Ian in this matter.

I think there are at least two cases where this issue comes up and is
importand, and where using a debian revision without separate upstream
tarballs is the right approach:

1) small packages currently maintained by the upstream maintainer where
debian revision is incremented for packaging only changes and upstream
revision is incremented for upstream versions

and

2) Cases typically outside the Debian archive where a git tree is being
built as a Debian package especially as part of a CI system and where
the effort of tracking upstream tarballs is undesired.

2) is more of an issue for lintian than it is for debian-policy.

While I feel strongly about this, and believe that  I adequately
explained my position years ago on debian-devel when dpkg first started
rejecting packages with debian revisions and 3.0(native) format,
I don't have the emotional energy for a discussion of this.
The way I was treated by the dpkg maintainer back then caused me to stop
working on Debian for months and seriously consider moving on to other
things.
I just don't have the emotional bandwidth to deal with a discussion
where well-considered arguments will be ignored and/or dismissed with
little consideration.

So, +1 on this, but don't expect me to be able to participate much in
the discussion.


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Felix Lechner]

Hi,

As a Lintian maintainer, I would like to express support for Ian's
effort to remove restrictions on Debian version strings.

Unlike Ian, however, I also believe all packages should be converted
to format 3.0. A package's 'nativeness' is then declared explicitly,
and does not have to be inferred from the version string.

Lintian still does the latter for installation packages (aka 'binary'
packages) because the expected changelog locations differ (and tags
are issued accordingly). In my view, nativeness should only matter for
source packages. The provenance of an installation package should not
matter.

I wrote this message because the Lintian bug that is blocked by this
one will be triaged in another way. Lintian supports Ian's effort to
the extent that it simplifies the parsing of version strings.

Kind regards
Felix Lechner