On Wed, Apr 11, 2018 at 01:54:58PM -0700, Russ Allbery wrote: > Ian Jackson <ijack...@chiark.greenend.org.uk> 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 think additional information in README.source is a very helpful thing to have. However, my *personal* policy for sponsoring a package is that I will not sponsor a package that comes without a method that enables me automatically to reproduce the upstream source tarball. Some vague advise in README.source like "download from xyz, check file abc, remove def, create a tarball with name mno_ver" is IMHO not acceptable. The fact that the get-orig-source was mentioned in policy enabled to give some pointer to a documented way to provide this code. After the removal I will surely stick to my personal policy but for an explanation who to implement it in a somehow standardized way I need do add extra information now. > 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? As I said before I'm fine with the removal from debian/rules but we should somehow settle with some default recommendation that avoids that every developer invents its own way to obtain the upstream source (if uscan does not work and I'm talking only about this case). If you think the better place might be Developer's Reference that would be OK for me. However, specifying the method would enable lintian to check something like If there is no watch file and the package is no native package you should provide debian/get-orig-source (or whatever you like to define instead) > 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. Regarding the depencencies for a get-orig-source target I once used a simple list inside the script and checked whether these packages are installed. I'd think it would be over-engineering to make this technically perfect and I agree that it is hard to specify. But simply requesting a method and checking whether this method is used is a good target for policy. Kind regards Andreas. -- http://fam-tille.de