Re: Broken Link in Policy HTML Page

[Sean Whitton]

Hello Paul, Russ,

On Tue, Jun 27, 2017 at 10:16:16PM -0700, Russ Allbery wrote:
> We should probably open a bug for this since it's not entirely obvious
> what to do here.  I can think of three options:
> 
> * Ask debian-www to publish the HTML version of that file as well.
> * Change the link to point to the wiki version of the file.
> * Convert the process doc to DocBook so that we can make it an appendix.
> 
> I'm kind of leaning towards the last, honestly.

Agreed.  It should be easy enough to convert back and forth with pandoc,
and it's much better to have this in our git repo than on the wiki.  An
appendix is also significantly easier for people to find.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

On Sun, Jun 25, 2017 at 04:01:43PM -0700, Russ Allbery wrote:
> > One rarer case is missing here:
> 
> > 1.2.3-4~deb9u1
> > Everything in 1.2.3-4 from unstable was in fact needed in Debian
> > 9, so it was simply rebuilt for Debian 9 and uploaded there
> > (prominent examples: firefox-esr, intel-microcode)
> 
> Is this widespread enough to be worth describing?  It's kind of hard to
> describe.

I for one had assumed that there was no difference between -deb9u1 and
~deb9u1, so I'd like to see it documented.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

On Sun, Jun 25, 2017 at 02:08:05PM -0700, Russ Allbery wrote:
> Concerns, objections, seconds?

Thank you for working on this.

> +A native package is software written specifically for Debian
> +whose canonical distribution format is as a Debian package.
> +Native packages have no separate upstream source in their
> +source package representation and no separate Debian
> +revision in their version numbers.  Native packages are an
> +exception: most Debian packages are "non-native" and have
> +source packages composed of an upstream software release and
> +separate Debian-specific modifications.

Native packages are also used for software that is intended for use
beyond Debian, but where the upstream maintainer also maintains the
Debian package.  In such cases, the Debian revision and orig tarballs
represent needless overhead (tweaks to the packaging can use an
increment to the minor version number, or similar).

Some people frown upon this practice, but there are more than one of us
that do it, so probably worth mentioning in policy as a secondary use of
native packages (possibly a footnote, due to lack of consensus?  There
is certainly not a consensus that it's terrible).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Broken Link in Policy HTML Page

[Paul Hardy]

Sean,

On Sat, Jul 1, 2017 at 7:55 AM, Sean Whitton  wrote:
> Hello Paul, Russ,
>
> On Tue, Jun 27, 2017 at 10:16:16PM -0700, Russ Allbery wrote:
>> We should probably open a bug for this since it's not entirely obvious
>> what to do here.  I can think of three options:
>>
>> * Ask debian-www to publish the HTML version of that file as well.
>> * Change the link to point to the wiki version of the file.
>> * Convert the process doc to DocBook so that we can make it an appendix.
>>
>> I'm kind of leaning towards the last, honestly.
>
> Agreed.  It should be easy enough to convert back and forth with pandoc,
> and it's much better to have this in our git repo than on the wiki.  An
> appendix is also significantly easier for people to find.

This is now filed as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866192.  I am CCing
this message there.

Thanks,


Paul Hardy

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Adam D. Barratt]

On Sat, 2017-07-01 at 16:00 +0100, Sean Whitton wrote:
> On Sun, Jun 25, 2017 at 04:01:43PM -0700, Russ Allbery wrote:
> > > One rarer case is missing here:
> > 
> > > 1.2.3-4~deb9u1
> > >   Everything in 1.2.3-4 from unstable was in fact needed in Debian
> > >   9, so it was simply rebuilt for Debian 9 and uploaded there
> > >   (prominent examples: firefox-esr, intel-microcode)
> > 
> > Is this widespread enough to be worth describing?  It's kind of hard to
> > describe.
> 
> I for one had assumed that there was no difference between -deb9u1 and
> ~deb9u1, so I'd like to see it documented.

fwiw, I can't think of situations where -deb9u1 would ever be used.
Either a selected set of changes were applied to the package in stable,
which would be +debXuY, or a newer upload was backported in its
entirety, which would be ~debXuY as above.

In terms of the use of ~ versions for stable updates being widespread,
there are currently eight packages in either stable-new or
proposed-updates using such versions and a further nine in the
corresponding suites for jessie. Several, but by no means all, of those
uses are in packages from the security archive.

Regards,

Adam

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

On Sat, Jul 01, 2017 at 04:46:21PM +0100, Adam D. Barratt wrote:
> fwiw, I can't think of situations where -deb9u1 would ever be used.
> Either a selected set of changes were applied to the package in stable,
> which would be +debXuY, or a newer upload was backported in its
> entirety, which would be ~debXuY as above.

Sorry, I meant s/-deb9u1/+deb9u1/.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Sean Whitton  writes:

> Native packages are also used for software that is intended for use
> beyond Debian, but where the upstream maintainer also maintains the
> Debian package.  In such cases, the Debian revision and orig tarballs
> represent needless overhead (tweaks to the packaging can use an
> increment to the minor version number, or similar).

> Some people frown upon this practice, but there are more than one of us
> that do it, so probably worth mentioning in policy as a secondary use of
> native packages (possibly a footnote, due to lack of consensus?  There
> is certainly not a consensus that it's terrible).

I thought there actually was a consensus that it's terrible.  I certainly
think it's not good practice.  I would recommend against anyone doing
this, speaking as someone who maintains lots of upstream software that I
also package for Debian, and therefore would rather not document it in
Policy, unless we're going to say not to do it.

Bumping the minor version for things that no one cares about (because they
only affect people consuming it from Debian) is probably between you and
your users, although I think it's poor practice and would be vaguely
irritated by it.  But the stronger argument against this approach is NMUs
and change of maintainership.  As soon as such a package is NMU'd for
whatever reason, or if you no longer have time to maintain the package for
Debian but are still developing it upstream, the native package status
gets really awkward.  At that point, the package is diverging from
upstream, but all the normal mechanisms to handle that divergence with
patch sets and whatnot are no longer available.

I've also repeatedly had the experience as upstream maintainer that I
actually do need to carry a Debian-specific patch for a while, since
Debian needs some quick fix that I don't want to take upstream in the same
form.  Which means that I want to use the patch handling mechanisms of
Debian even for myself.  And the overhead is basically nonexistent once
you get your tools configured and a workflow set up.

Whenever this came up on debian-mentors, it seemed to me like there was
fairly strong consensus that native status should only be used for
software with no independent existence, and as soon as there's a separate
upstream release and Debian packaging, it's better to just do the setup
work to have a non-native package.

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

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[gregor herrmann]

On Sat, 01 Jul 2017 08:52:29 -0700, Russ Allbery wrote:

> Sean Whitton  writes:
> 
> > Some people frown upon this practice, but there are more than one of us
> > that do it, so probably worth mentioning in policy as a secondary use of
> > native packages (possibly a footnote, due to lack of consensus?  There
> > is certainly not a consensus that it's terrible).
> I thought there actually was a consensus that it's terrible.  I certainly
> think it's not good practice.  I would recommend against anyone doing
> this, speaking as someone who maintains lots of upstream software that I
> also package for Debian, and therefore would rather not document it in
> Policy, unless we're going to say not to do it.

FWIW, I agree, and I also think that this as close to a consensus as
any issue in Debian can get.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: U2: When I Look At The World


signature.asc
Description: Digital Signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Wouter Verhelst]

On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
[...maintaining non-Debian-specific software as a native package...]
> I certainly think it's not good practice.

I think it depends on the particulars of the situation.

I am upstream for two of the packages I maintain for Debian: nbd and
fdpowermon.

For nbd, I maintain it as an upstream package on sourceforge and github,
and as a non-native Debian package.

For fdpowermon, I just maintain it as a native package. I do this,
simply, because the package is fairly trivial -- the most important bit
is a (currently) 573-line perl script (and that's including POD
documentation). While it's certainly possible to ship an "upstream"
Makefile.PL or some such with this package, that feels like overkill and
generally not worth it. Additionally, the packaging is so simple that
updating the package for just the packaging is rare, if it even happens
at all, so just about every update I've ever done was relevant for
people who did not use Debian, too.

While I agree that Debian is not a general software distribution
platform, and that therefore shipping software like this isn't
necessarily a good idea, for me as a Debian developer it is
significantly easier to just maintain it this way and not have to worry
about the extra overhead (even if it's a pretty small overhead) that an
"upstream" release would involve.

[...]
> Bumping the minor version for things that no one cares about (because they
> only affect people consuming it from Debian) is probably between you and
> your users, although I think it's poor practice and would be vaguely
> irritated by it.

I can see why that might be the case, but given that in the case that I
quote above that is actually quite rare, I'm not sure it's a problem.

> But the stronger argument against this approach is NMUs and change of
> maintainership.  As soon as such a package is NMU'd for whatever
> reason, or if you no longer have time to maintain the package for
> Debian but are still developing it upstream, the native package status
> gets really awkward.

I'm not sure this is true.

By uploading a native package into Debian, I take the "risk" that at
some point someone will have to do an NMU, yes. Indeed, if I instead
hosted the package on some upstream hosting site, then nobody but me
will be able to do releases of fdpowermon. But that's not a major issue;
I trust that my fellow developers won't abuse that right (indeed, they
don't usually do so).

If I ever find myself in the situation where I stop maintaining
fdpowermon in Debian but continue maintaining it upstream, then
converting the package from a native to a non-native one is fairly
trivial. In fact, I've occasionally uploaded nbd as a native package by
accident, because dak doesn't actually care, and neither do our build
tools (when using source format 1.0). As such, if that situation ever
happens, then moving to a non-native package is trivial, and there is no
awkwardness.

[...]
> I've also repeatedly had the experience as upstream maintainer that I
> actually do need to carry a Debian-specific patch for a while, since
> Debian needs some quick fix that I don't want to take upstream in the same
> form.

Indeed; for nbd, I've occasionally had to do that as well. Usually it's
a cherry-pick from upstream master or some such, where a bug was first
exposed in one of our more obscure ports; and while I do want to release
it upstream, just doing a new upstream release just so I can release a
bugfix for alpha or hurd or whatnot isn't really worth it.

For a simple perl script which by its very nature has little portability
issues and therefore small chances for requiring such patches, I don't
think it's worth fussing about though.

A somewhat more complicated example is ikiwiki; when Joey was still
maintaining it for Debian (before he resigned from the project), it was
also a native package. At the time, the package version number was just
the git checkout date, as in, "we don't really do upstream releases,
what's in Debian is just a snapshot from the git repository". That, too,
seems like a reasonable approach to me.

I guess what I'm saying is that it really depends on the particulars of
how you maintain the software; and that while in general it's probably a
bad idea, there can be corner cases where it isn't necessarily a bad
idea, can even be a good idea, and certainly takes away some overhead
and extra work that wouldn't be necessary at all if not for the fact
that you're doing a non-native version and therefore need to do an
"upstream" release before you can do a Debian release.

Regards,

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab