On Fri, Aug 28, 2015 at 07:42:42AM +0200, Vincent Bernat wrote: > >> The main effect of this religious and overzealous application of our > >> guidelines is that people just stay away of JS stuff in Debian and > >> packaging any web-related app is becoming more complex as anyone needs > >> to deal with JS stuff in its own package.
> > Yes, that is a danger. I think putting those things in contrib should be a > > good solution if rebuilding is such a big problem. Because if it is, the > > code > > really really doesn't belong in main. > What will happen is that maintainers will fallback to the second less > horrible solution and cripple the package (by using an older version of > the JS lib for example) to allow it to stay in main. And here will come > the angry users and the bad PR. Sometimes taking a principled stance means that people who don't understand (or don't agree with) those principles will be angry. This is not a justification for abandoning our principles. I take a dim view of Debian Developers who argue that their packages should have an exception from the requirements for Debian main because it's hard. Sorry, sometimes software is hard. The constructive thing to do here is to ask other developers who care about this issue (and this thread shows there are clearly quite a few) to commit to help with improving Debian's tooling for JavaScript packages, not to pretend that DFSG#2 doesn't apply to JavaScript. "The program must include source code", and by any measure, minified JS is not source code. And it's not like minified javascript is some negligible corner case; the browser paradigm has come to so dominate our user experience over the past few years that this now represents a major modality of software that users interact with. Yet you try to compare this with autoconf. Even if we tolerated configure scripts today in the archive that we can't rebuild using the software in Debian (which by and large we do *not* tolerate - because we've learned our lesson), there's a big difference in impact between a build script used once at package build time and never shipped in the package to our users, vs. swaths of user-facing UI code. > I won't put a package of mine in contrib because of such a technicality: That's ok, the ftp team is more than capable of taking care of this on your behalf if you're not going to take responsibility for meeting the requirements for main. > all the code is free software and is provided with the appropriate > source. A tiny part of it is difficult to rebuild from scratch. I don't know if this is true or not; the only package you've used as an example in this thread is jquery 3.0.0-pre, which is a) not a package you're the maintainer of, and b) not a version of the package that's present in Debian. Nevertheless, for packages that *are* in Debian, we should expect that the source package contains the *full* corresponding source code for any minified javascript files. If we can't rebuild it then we don't actually have the source, and that's a practical as well as philosophical problem for Debian and for our users. Yes, packaging a new and fast-moving ecosystem according to Debian's standards is a lot of work. Let's figure out the best way to do that work, instead of pretending that Debian's standards don't matter. Or if there's really no way to do the work that can simultaneously meet Debian's and upstreams' needs, then let's move the packages to contrib if that's where they're supposed to be. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
