Bug#515856: Debian Policy 4.1.4.0 released

[Russ Allbery]

Jonathan Nieder  writes:

> Context: I have run into a few packages that used the +dfsg convention
> without documenting what they removed from the tarball and I was not
> able to locally update them. :(

This is one of the cases that now has a better solution and more standard
tools than the get-orig-source target, specifically Files-Excluded in
debian/copyright.  See the documentation of Files-Excluded in uscan(1).

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

Bug#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon, Jul 02 2018, Jonathan Nieder wrote:

>> I'm a bit confused: wasn't it already specified pretty precisely?
>
> Please take a look through the bug's discussion.  It's explained why the
> wording was not thought to be good enough.

Thanks.  This looks like a classic case of letting the perfect be the
enemy of the good (or perhaps, of not understanding the use case for
which the existing practice was good enough).  Some quotes from the
bug:

| According to codesearch.d.n, get-orig-source is implemented by less than
| 3000 source packages. This is not very low, but neither a high adoption
| rate. It certainly makes using get-orig-source somewhat useless on a
| distribution-scale.

Certainly it's even more useful to have a debian/watch file, but this
doesn't make it clear to me what I'm supposed to do with those 3,000
source packages now.

|  * The requirement that get-orig-source may be invoked from any
|directory is difficult to fulfil and often times not implemented. A

This hasn't been an obstacle to my use.  I can even try multiple
directories.  What's helpful for me is that it works from *somewhere*.

|  * It is not clear whether the most recent upstream version or the
|currently packaged version should be downloaded.

Likewise, either works fine for my use.

|  * It is not clear where required tools should be declared.

As long as the command prints an error about the required tool, I can
install it.

| We're just reducing
| the documented interfaces of packages a bit based on current trends,
| which is useful for newcomers to Debian.

What is a newcomer supposed to do now when they encounter a package
that does not provide an explanation of how to generate the upstream
tarball?

Jonathan

Bug#515856: Debian Policy 4.1.4.0 released

[Sean Whitton]

Hello Jonathan,

On Mon, Jul 02 2018, Jonathan Nieder wrote:

> I'm a bit confused: wasn't it already specified pretty precisely?

Please take a look through the bug's discussion.  It's explained why the
wording was not thought to be good enough.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed, Apr 11 2018, Russ Allbery wrote:

>> I'm pretty reluctant to specify this sort of optional target that
>> works differently in every package that uses it back in Policy because
>> it's really not standardized, nor do I think it's possible to
>> standardize.  If we really want to write something down about the
>> target, maybe the Developer's Reference would be a better spot?  There
>> were a whole host of issues with having this in Policy that were
>> resolved by moving it outside the scope of Policy, such as how to
>> document dependencies required for running the get-orig-source target.
>
> The Developer's Reference seems like a more appropriate place for a
> convention that it is not possible to specify precisely.

I'm a bit confused: wasn't it already specified pretty precisely?

I would be in favor of adding the target back, with a description
along the lines of "If you provide a get-orig-source target, it should
satisfy .  If you provide neither a get-orig-source
target nor a debian/watch file and you do not use an archive from
upstream as-is, please include clear instructions in README.source to
allow a human to produce an upstream tarball."

Context: I have run into a few packages that used the +dfsg convention
without documenting what they removed from the tarball and I was not
able to locally update them. :(

Thanks,
Jonathan

Bug#515856: Debian Policy 4.1.4.0 released

[Sean Whitton]

Hello,

On Wed, Apr 11 2018, Russ Allbery wrote:

> I'm pretty reluctant to specify this sort of optional target that
> works differently in every package that uses it back in Policy because
> it's really not standardized, nor do I think it's possible to
> standardize.  If we really want to write something down about the
> target, maybe the Developer's Reference would be a better spot?  There
> were a whole host of issues with having this in Policy that were
> resolved by moving it outside the scope of Policy, such as how to
> document dependencies required for running the get-orig-source target.

The Developer's Reference seems like a more appropriate place for a
convention that it is not possible to specify precisely.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#515856: Debian Policy 4.1.4.0 released

[Russ Allbery]

Ian Jackson  writes:

> (ii) You make a very good argument that policy should continue to give
> guidance for this kind of situation.  The target should probably be
> put back in policy, but with an explicit note saying it's not normally
> desirable, or something.

I think the Policy guidance is that you should document your maintenance
procedures in README.source if they're unusual, which would include this.
In that documentation, you can reference whatever scripts or targets would
be involved in doing an update.

I'm dubious there are really that many cases where knowing about a
get-orig-source target is the *only* piece of additional information
required about a source package and everything else is entirely standard.
I would expect somewhat non-standard upstreams to need at least some
additional explanation (how to choose a good upstream commit to package,
for instance).

I see that the current wording in Policy about README.source doesn't call
out this case (upstream updates) explicitly.  Maybe it should.

I'm pretty reluctant to specify this sort of optional target that works
differently in every package that uses it back in Policy because it's
really not standardized, nor do I think it's possible to standardize.  If
we really want to write something down about the target, maybe the
Developer's Reference would be a better spot?  There were a whole host of
issues with having this in Policy that were resolved by moving it outside
the scope of Policy, such as how to document dependencies required for
running the get-orig-source target.

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

Bug#515856: Debian Policy 4.1.4.0 released

[Ian Jackson]

Andreas Tille writes ("Re: Debian Policy 4.1.4.0 released"):
> In other words: I'm fine with removing the target in rules and replace
> it by:
> 
> If there are reasons why uscan can not fetch the upstream source it
> is recommended to provide a script debian/get-orig-source .
> 
> If we do not provide *code* to get the upstream source and just settle
> to some (however vague) description in d/README.source random package
> developers who might work on a package will end up with different
> results.  This should not be the outcome of a policy change.

I'm not sure why you would change from a rules target to a custom
script.

There is an argument that rules-as-makefile is not the ideal interface
and implementation strategy, but I doubt that here and now is the
right time to be making an accidental transition away from that.

If the only reason is that the docs for the target are being removed
from policy, then:

(i) The fact that a target is no longer documented in policy does not
mean it should not be provided; the fact that a target is being
removed from policy does not mean it should be removed from packages.
It means merely that the target's purpose and inclusion should be
reconsidered.

(ii) You make a very good argument that policy should continue to give
guidance for this kind of situation.  The target should probably be
put back in policy, but with an explicit note saying it's not normally
desirable, or something.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#515856: Debian Policy 4.1.4.0 released

[Andreas Tille]

On Sun, Apr 08, 2018 at 10:58:53AM +0200, Ole Streicher wrote:
> >
> > Imho Sean's last mail sums it up pretty well
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94
> 
> I have read this, but it does not convince me. My rule to get the
> upstream packagage was always: use uscan, if d/watch exists, otherwise
> use get-orig-source. Sounds pretty simple and straigt-forward. If it
> fails, I had a starting point where to debug (usually just a missing
> dep). I see no reaso why this should be given up.

I agree with Ole.  While I took over some ideas from this thread how to
get rid of some get-orig-source targets by using mode=git I think it
makes perfectly sense to define a target name that should be used in
case uscan can not be used exclusively to fetch upstream source.  I can
not see in how far definition of the target name will harm - but from
the point of team maintenance it helps to know where to look first to
download a new upstream version.

BTW, I have standardized all my packages to

get-orig-source:
. debian/get-orig-source

In other words: I'm fine with removing the target in rules and replace
it by:

If there are reasons why uscan can not fetch the upstream source it
is recommended to provide a script debian/get-orig-source .

If we do not provide *code* to get the upstream source and just settle
to some (however vague) description in d/README.source random package
developers who might work on a package will end up with different
results.  This should not be the outcome of a policy change.

Kind regards

  Andreas.

-- 
http://fam-tille.de