Re: Debian Policy 4.1.4.0 released
On Wed, Apr 11, 2018 at 02:29:25PM +0100, Ian Jackson wrote:
> 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.
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.
Yes.
> (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
Andreas.
--
http://fam-tille.de
Reply to: