[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Policy 4.1.4.0 released



Hi Sean,

On Tue, Jul 03, 2018 at 09:59:55AM +0100, Sean Whitton wrote:
> [trimming the CC a bit; Russ and Ian read -devel]
> 
> Hello Jonathan, Andreas,
> 
> I don't think that what either of you have said is a response to the
> reasons that there were for removing this optional target from Policy.
> 
> The thought driving this is that not every trick in a Debian package
> maintainer's toolbox should be detailed in Policy.  What we want to
> write down here are techniques that apply to most packages, where the
> cases to which the techniques do not apply can be written down too.
> 
> The problem with get-orig-source is that it is always an edge case.
> It's only needed when d/watch and Files-Excluded aren't sufficient,
> which already puts you out in the weeds, and it is going to need to work
> differently in every package that uses it.  So it doesn't make sense to
> standardise it.

We had discussed this some weeks ago.  My answer was:  Policy should
enforce that any random person gets a tool to reproduce the upstream
tarball.  Usually it is uscan but if there is no chance to accomplish
that task with uscan some alternative should be provided.  I have seen
many such "edge cases" and IMHO policy should cover all packages
including edge cases.  We are extremely picky to document the copyright
and license of every single file in a source tarball.  I fail to see a
good reason why we should not encourage maintainers to also provide code
to fetch those files.
 
> However, the use cases that you raise are valid, and I agree with you
> that package maintainers should make it possible for users to extract
> the information that the two of you are trying to extract.  They might
> do that by providing a rules target called get-orig-source, which is
> perfectly allowed.  But that's now package-specific machinery.

I understand that the sense of the policy change is that it is package
specific and that I'm allowed to use it.  However, I'm now missing a
highly ranked documentation to point a newcomer to which answers the
question how to fetch the source code if uscan fails.
 
> It seems that what you actually want is not a very loose and unhelpful
> get-orig-source convention, but a recommendation or requirement that
> package maintainers make it possible to obtain a list of the files that
> were excluded, or similar.  Maintainers could fulfill that using
> Files-Excluded, a rules target, text in README.source, or whatever.

Not really, I do not want to use README.source or something like this.
I have a *personal* policy:  I will not sponsor any package if there is
no code I could run that recreates the source tarball.  May be I'm to
strict and the sponsee might find some other sponsor.  The Debian policy
change simply weakens my point where I think there are very good reasons
for.

> If you think you know exactly what that recommendation or requirement
> should be, please file a new bug proposing its addition to Policy.
> That's something that it makes sense to standardise, unlike
> get-orig-source.

I would love to create a new bug report but this would rather be:

   Provide get-orig-source target if (and only if) uscan would fail.

The previous discussion seem to show a tendency that this bug will
be at best tagged wontfix which for the moment prevents me from
calling reportbug right now.

Kind regards

         Andreas.
 
> On Tue, Jul 03 2018, Andreas Tille wrote:
> 
> > Since this does not exist any more I'm afraid we will end up with more
> > upstream tarballs a third person will not have any clue how to fetch
> > the source.  IMHO that's an unfortunate change in policy.
> 
> I don't see why removing an /optional/ target, which you can still use
> if you want to, makes it likely we'll end up with more such source
> packages.  The fact that the target isn't there won't make it much less
> likely someone will think, "I should ensure the tarball is fetchable."
> 
> -- 
> Sean Whitton



-- 
http://fam-tille.de


Reply to: