Neil Williams <codeh...@debian.org> writes: > On Fri, 25 Apr 2014 01:16:04 +0100 > Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote: > > > I don't think that we should go and do the tedious work of repack > > thousands of packages because of this, with no real benefit in terms > > of freedom (or any other) for our users -- provided that we depend > > and link to the canonical versions in the binary packages.
We promise the source for everything any recipient downloads as part of Debian. If non-source files are distributed in Debian source packages, without a way to confidently guarantee the corresponding source is what's already available in Debian, then that is a definite impact on the freedom of Debian recipients: it threatens the freedom promises in the Social Contract. > Talk to upstream, get them to package the unminified JS or no JS in > their releases, then minify during the build. If the built version > matches a packaged version, then do the dh_link but not otherwise. One special problem with minified Javascript, in works that are web applications or components in particular, is that upstream commonly has: * No distinct “source”: They distribute only files that recipients are expected to use as-is. * Bundled third-party pre-compiled Javascript files, which the immediate upstream doesn't bother to get the source form, let alone make the source form available to recipients. * No managed “release”: they expect people to just get whatever is currently in the head revision of the VCS repository. * No automated “build”: they collate the bundle of files and expect recipients to simply deploy the downloaded files as-is. So in the case of many such upstreams, the discussion we'd like to have, focussed on “please separate the source Javascript in your release from the compiled result in the build”, quickly expands in scope because such a request can only be addressed by first introducing: * The concept of the package source as separate from the deployed result; * The concept of releasing such source in a form not intended for immediate as-is deployment; * The concept of maintaining such a source build for download; * The concept of obtaining the (frequently third-party) Javascript in source form rather than just passing along a pre-compiled file; * The concept of a separate build step to transform the source, as distributed, into a deployable application; * The concept that some recipients want to build from the upstream developer's source files on their own, independent of the upstream developer; and other related matters. Many such upstreams will, in my experience, when the discussion expands to encompass the all these concepts for which they perceive little need, attempt to wave the whole discussion off as too much effort to satisfy what appears to be a minority of recipients with bizarre requests. So tackling this issue with such upstreams requires a lot of education, diplomacy, patience, and respect for their position: these all tend to be problems that they've not felt the need to address to date, and as Debian maintainers we need to help them understand the benefits. None of this detracts from the truth of what you say: we need more dependable source distinct from build artefacts, more dependable source releases, more dependable build procedures, more dependable versioned APIs, etc. All of this feeds into the issues of freedom for the recipient of the work. -- \ “Some people have a problem, and they think “I know, I'll use | `\ Perl!”. Now they have some number of problems but they're not | _o__) sure whether it's a string or an integer.” —Benno Rice, 2011 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857g6dmuje.fsf...@benfinney.id.au
