Web lists-archives.com

Re: Debian Policy released

On Wed, Apr 11, 2018 at 02:29:25PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: Debian Policy 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.

I personally did it since you can save a lot of syntax things like "; \"
at end of lines etc.  I would not make it a common rule but I became
simply used to it.
> 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.

The argument of the bug report was that dh does not know the target.
Since d/rules is usually interpretet by dh I understand the arguing
to not describe something that can not be interpreted by dh.
> 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.

That is exactly what I wanted to express.  I do not mind the actual
implementation but writing down in policy that there should be some
common interface to obtain the upstream source as a fallback to uscan
(and only as fallback if there is really no chance to use uscan) seems
important to me,

A wording that makes bug reports of high severity possible saying:

   Package is using get-orig-source instead of uscan

is fine for me. 

Kind regards