Quoting Joachim Breitner (2014-03-11 11:29:31) > Am Dienstag, den 11.03.2014, 11:22 +0100 schrieb Jonas Smedegaard: > > Quoting Russ Allbery (2014-03-11 03:32:54) > > > Paul Wise <pabs@debian.org> writes: > > > > > >> I'd suggest an acceptable workaround is to include the source in the > > >> debian.tar.gz/diff.gz or to repack the upstream tarball, probably the > > >> latter since jQuery is usually an embedded code copy. > > > > > >> https://wiki.debian.org/EmbeddedCodeCopies > > > > > > Note that we do not (and should not) repack upstream source for > > > embedded code copies that are not used in the build, if there are no > > > other issues with those copies. It's sufficient to just not use them. > > > > I agree that there are better ways than repackaging. > > > > I disagree that "just not using [parts lacking true source]" is one of > > them. Instead I find that the combination of these is acceptable: > > > > a) Include the "true source" in our addendum (the diff for v1 or the > > tarball for v3 source formats) > > b) Ensure that "reformulated source" in the tarball we redistribute > > pristine is indeed a reformulation of the "true source" (e.g. by > > comparing checksum against same processing done once) > > > > That's more elegant in that we ship pristine upstream tarball, but not > > simpler because it puts the burden on the package maintainer to prove > > that the source we redistribute was not altered only reformulated. > > I see how that is solves the problem, and how it is idiologically > desirable, but is it worth it? Consider this: > > I find a package that ships some-lib.min.js without source. It happens > that we have libsomelib-js in Debian. So I > > 1. Make debian/rules not install some-lib.min.js into the binaries. > 2. Change e.g. the HTML files to point to the file in > libsomelib-js. > 3. Try to find out what precise version some-lib.min.js is. > 4. Hunt down the source package for that version and include it in > debian/ > 5. Build that to get another copy of some-lib.min.js is. > 6. Compare it with the one shipped by upstream. > 7. Possibly tweak build settings until the results are the same, > trying out various minimizers and options. > > Of these 7 steps, only the first two actually affect the resulting > package, i.e. our users. From a practical point of view, I don’t believe > that we should spend time on 3-7, and instead replace it by > > 3. Ensure that we can legally distribute libsomelib-js > 4. Add it to debian/clean (or maybe Excluded-Files), and be done with > it. Yes, I did not mean to say that the tedious 7-step process is the only possible way, just that it was _a_ possible way to avoid repackaging upstream tarball but redistribute it pristine. Your alternate 4-step process is an easier but uglier alternative. If you care only about those of our users that consume binary packages, you may not even recognize the 4-step procedure as uglier ;-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature