Re: Non-source Javascript files in upstream source
On Fri, May 02, 2014 at 03:58:37PM -0400, Paul Tagliamonte wrote:
> On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote:
> > Is there any disagreement about this? As far as I've understood so far, there
> > are only two points that keep being discussed:
> >
> > 1. Do we need to check that generated files which we don't use are actually
> > generated from the provided source? Main example here is a configure file
> > which gets overwritten during build.
>
> Yes. Please see the email. You need to make sure you have source for
> everything. If you're not shipping the raw source (e.g. most Python), be
> sure you're making the binary in your rules file, and using that binary
> in the deb.
This was not the point I wrote about, and AFAIK not a point that is contested.
What I was saying is: We have a configure file, and we have a configure.ac,
which upstream claims was used to generate the shipped configure. During
package build, we ignore the shipped configure file and generate a new one from
configure.ac. Up to this point, AFAIK there is consensus about everything.
The contested point is: what do we do with the shipped (and unused) configure
file? Do we need to check that upstream's statement (that it was generated
from configure.ac) is correct (or more likely, remove configure from the source
package because we can't really check this)? Or can we trust upstream on this?
> > 2. What is source for a non-programmatic work such as a rendered bitmap of a
> > 3-D model, do we require source for non-programmatic works, and if not, what
> > defines a programmatic work?
>
> Preferred form of modification. Yes, there exist edge-cases (an image
> made from a photo taken of someone which had two pixels flipped after
> putting it through scanner after skydiving while drawing it), but I
> think good judgement here is fine.
I tend to agree with this. My point wasn't that I don't have an opinion, but
that there isn't consensus on this. Which is illustrated by the replies to
your statement. ;-)
> > Neither of these is clarified by their recent statement.
>
> I believe they are. We require source. This applies to source packages.
> If you don't have source, don't include the thing. If you have the
> source, rebuild it at build time.
For point 1, the contested part is "are we sure configure.ac is the source for
configure?" and in point 2, it is "does a file exist which is source code for
this file, or should it be considered source itself?"
On Fri, May 02, 2014 at 07:47:08PM -0400, Theodore Ts'o wrote:
> If someone starts complaining that I shipped a version of configure
> that corresponded to autoconf version N, and sid just uploaded N+1,
> and therefore my configure doesn't match with my configure.in, and
> that's therefore a DFSG violation, I'm going to be really annoyed.
Yes, I don't think anyone is suggesting that this is a problem. If configure
was generated from configure.ac, even if you can't regenerate the exact same
file with your system, that configure.ac is still its source.
This is about the unlikely case where upstream ships a new configure and an
outdated configure.ac, so that the build process works better using the shipped
configure than when regenerating it.
If this would actually happen, I think everyone would agree that this configure
file doesn't have source in the package and cannot be in Debian. This is
however very unlikely and several people are saying "let's just trust upstream
that they don't do this and not waste our time on it", which I think is a valid
argument. On the other hand, removing the file from the source package isn't a
lot of work either. But do we want to repackage all of our source tarballs?
Also, we'd be sending a signal to the community that files such as configure
don't belong in a release tarball, while they really do: they make it easier to
compile the program on a system with bad or broken tools. Debian doesn't need
that, but that doesn't mean we want to tell upstream not to include it.
> Heck, when autoconf has been busted, there have been times that
> modifying the configure script directly *was* my preferred form for
> making modifications....
Ah, and what to do then? If we would decide that we remove configure because
we don't want to check, that really means in such a case you must check that
the configure before you made modifications to it is generated by configure.ac
(if you wouldn't need to check that, we also wouldn't need to check the other
cases). And that doesn't seem like something that reasonably can be done.
So for those who claim that we need to remove configure files: how would you
handle this? Is this an exception? Is the maintainer (or upstream) not
allowed to do this?
Personally, I like the idea of trusting upstream that configure.ac is source
for configure, and we don't have to remove configure from the source package
(assuming configure.ac is there, of course).
On Sat, May 03, 2014 at 10:59:50AM +0900, Charles Plessy wrote:
> Le Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen a écrit :
> > Neither of these is clarified by their recent statement.
>
> I totally agree
No, you make a different point. ;-)
> Altogether, this calls for clarifying what a “program” is.
Yes, that would solve the second point of discussion that I mentioned.
Thanks,
Bas
Reply to: