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
