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