On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich <mrvn@renich.org> wrote: > * Neil Williams <codehelp@debian.org> [150902 10:22]: > > Upstream is another recipient of code distributed under copyleft. > > Having changes in a format which upstream can use is absolutely a > > sensible and sane criterion for what is regarded as the form of the > > code for modification. To do otherwise is to make the maintenance > > burden untenable. > > > > Every recipient needs to get the source code and the maintainer > > changes in a format which is suitable for modification and that > > includes the work of modification required to incorporate those > > changes into the next upstream release. To rule out upstream > > requirements is nonsense. > > The whole point of this discussion is what does Debian require of > upstream for upstream to get its software distributed in Debian main. > It is presumed that upstream already has what it considers "source"; > in the case of this thread, that is minified JS. Actually, not. Source, for upstream of JQuery at least, is a set of directives to include files into a non-minified jquery.js which is then minified as part of the build in Debian. At that point, we're all good. It's when other packages have to have other bits of jquery which aren't packaged or are out of date in Debian and end up pulling those in as .min.js - there needs to be a way of still using those whilst allowing for fixes to be applied and used. That is what we lack - the ability to rebuild embedded .min.js from *any* source for modification. The problem is that the further that tool diverges from the variety of tools used by the variety of JS upstreams, the more likely it is that Debian will introduce further bugs into the .min.js which the JS upstream will not be able to reproduce. There are three players: 0: Debian - needs to fix problems in JS wherever we find them. 1: The JS upstream and their non-packaged minifier - may be unaware of the problem and have their own "source for modification" format. There may be a maintainer in Debian, likely there is not or the package is too far out of date. (JS upstreams where the code is up to date must be dealt with by symlinks into the packages using that JS.) 2: The embedding upstream who use the .min.js but need a way of patching actual source JS and rebuilding a new .min.js which is, hopefully, as close to the old one + that one fix as possible without introducing further bugs. If there's no embedding upstream, the JS doesn't matter to Debian - we aren't likely to find bugs in unused libraries of any language, except FTBFS and someone will probably file an RM RoQA. If the embedding upstream is writing JS of their own, then they need a minifier in Debian main too. None of those players are using or can use the minified JS as source or for any form of modification other than rebuilding. The current players are using *different* formats for modification and all lack packaged or consistent tools to get from one to another. It is a complete mess - with the embedding upstreams lost in the middle with no idea of what they can do to avoid getting in the way. > My point is that if what upstream considers to be "source" is not > acceptable to Debian, and the Debian packager has to grab real source > from other places and use a build process that is different from what > upstream uses in order to make the Debian package satisfy the DFSG, > then upstream's wishes are not relevant to whether the Debian package > conforms to the DFSG. There are different upstreams here. The upstream of the package embedding the minified JS, yes, that situation needs a fix. The upstream of the original JS that went into the minified JS has a different source for modification again - and that one is likely to be one of the ones which needs a whole gamut of packages to run the minifier that actually produces the embedded .min.js. No JS or embedding upstream is going to work with the .min.js as modifiable source. That's clearly nonsense. What is happening is that upstreams who need to embed JS are not finding the packages available and therefore embed and then reference that file in that upstream as .min.js. The solution is to have a way of rebuilding that .min.js in Debian so that fixes can be applied to the available JS for that file - and yet the upstream for that JS file is likely to have a different build process from that, so we end up with three possible source formats for modification - JS upstream, embedded unminified and the one nobody can actually modify but the one everyone wants to rebuild: minified. > Furthermore, if the Debian packager does not like upstream's > arrangement of source, even if it would satisfy the DFSG, and wishes > to rearrange it, whether or not the packager's arrangement satisfies > the DFSG's meaning of source should be judged on its own merit, not > on whether upstream is willing to accept patches based on the Debian > packager's arrangement. It's up to the maintainer to handle upstreaming of changes but it is a lot easier if maintainer and upstream agree. An embedding upstream are happy to get the unminified JS - provided the .min can be built. The JS upstream, likely as not, have a different format and a different minifier, so unminified JS used by the embedding upstream isn't going to be relevant. Right now, embedding upstreams are in a tangle. There's no clear way to rebuild the .min.js and the "source" is not necessarily what the original upstream actually edits. > I am _not_ saying this this is necessarily a good decision. The > distinction is between the DFSG, which is one part of the Debian > Social Contract, and the whole DSC. DSC point 2 requires that the > Debian maintainer give back to upstream. But that has nothing to do > with what satisfies the DSFG definition of source. In practical terms it does, because the maintainer is not going to look after two different formats without a tool to convert to and fro. Most JS upstream build tools don't go in reverse, so the released source used by the embedding upstream is not useful to the JS upstream. The harder it is to introduce or update JS which isn't yet packaged or is already out of date, the worse this problem will become. > My argument is not that Debian should not use a form that upstream > likes, but that the definition of "source" for purposes of the DFSG is > independent of upstream's definition of source. If both source forms > A and B satisfy the DFSG, and upstream uses form A, that does not make > form B fail to satisfy the DFSG, even for Debian packages of > upstream's software. Somewhere in the chain, the original upstream for the JS embedded into some other package will benefit from having changes from Debian made available in a format which can be integrated into that upstream. The other upstream, the one embedding the .min.js, will also benefit because then a new .min.js will be available from upstream containing fixes from other distros as well as Debian, maybe. Debian benefits if the JS upstream is simple to introduce and maintain in Debian because embedding upstreams can remove the embedded copy and symlink to the JS we all want to use - properly maintained, packaged JS built and minified with tools in main. If we forget about or disregard getting the security fixes from Debian into JS upstreams and concentrate only on the embedding upstreams, we will go backwards. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp9jlhdNuBXD.pgp
Description: OpenPGP digital signature