Raphael Hertzog dijo [Mon, Feb 19, 2018 at 03:19:59PM +0100]: > On Fri, 16 Feb 2018, Jonathan Carter (highvoltage) wrote: > > > - we could relax our requirements and have a way to document the > > > limitations of those packages (wrt our usual policies) > > > > Which requirements are you referring to? If it's relaxing the need for > > source for minified javascript, then no thanks. > > Instead of requiring the source to be provided in the source package as a > non-minified file, we could require the packager to document in > debian/README.source where the upstream sources actually are.
Pointing to sources outside our system might go away, and that would make us instant-buggy. That's why we have introduced the debian/missing-sources mechanism; your source package bloats, but is source-complete. Further, you can parse them with the "correct" minifiers and compare the results are identical (or provide our minified versions if they are not). > When I was maintaining wordpress, I introduced the idea of providing > debian/missing-sources/ to comply with the Debian policy. Yay, so it's not you who I have to lecture on this ;-) > I would just dump there the upstream tarball of the bundled > libraries to be sure that we have the source for the correct > version. The Debian/ftpmaster rules are respected but it's not > really better than the above because you still don't have a simple > way to rebuild a modified version of the javascript library shipped > in the package. build-depend on yui-compressor, node-uglifyjs-webpack-plugin, libjavascript-minifier-perl, or whatever minifier suits you; add them to the binary package in debian/rules instead of just copying over the upstream-provided minified versions. That is, think of minification as you would think of compilation. > So instead of ugly work-arounds, it might be better to just acknowledge > that we can't have the same level of support for all applications. > (...) > Those applications could rely on the package manager of their ecosystem to > setup the dependencies as they need them without polluting the host > system. ...But that pollutes the host system for all of their ecosystem. And that's what I suggest - Paraphrasing the SC, «We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines». We might come up with an area similar to contrib or non-free (or even decide to ship such systems there, as they kind-of-belong there!) Maybe Drupal, WordPress, NextCloud or WhatEver are not non-free by themselves. But they are not allowing for a practical source distribution; they force our hands into trusting software we cannot vouch for or give warranties on. So, maybe they belong in non-free.