On Wed, 07 May 2014 20:14:50 +1000 Ben Finney <b...@benfinney.id.au> wrote:
> Wouter Verhelst <wou...@debian.org> writes: > > > Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte: > > > If you were to 'update' the image, how would you do it? What > > > things would you need? Include that. Think about what you'd need > > > when you fork the project. > > > > Does that mean I should include "wget"? > > I'm sure you know this, and I am having difficulty interpreting your > question in good faith. But in case you actually don't know: > > Paul is referring, by “what things do you need?”, not to tools used, > but to the *form of the work* for making modifications to it. Clearly > the “wget” program is not a form of any work except the “wget” > program. > > As an aside to Paul: This is a prime example why a clear definition of > “source” in terms of the “form of the work” is needed: you need to be > clear you're talking about a specific *form of the work*; in > particular, the preferred form of the work for making modifications > to it. In terms of updating the package, I don't consider that it is good enough to assume that the following sequence does not provide *all* of the source code necessary to modify all parts of the package, in the form preferred for modification: $ apt-get install <package> # to get the runtime dependencies $ apt-get source <package> $ apt-get build-dep <package> That needs to include the probability of updating the package to use a new version of the JS code which is needed by the package. I'm applying this upstream too - the code is susceptible to bugs on version changes in the JS code, so we'll be packaging known good versions and only symlinking when those versions are available. At least, that's the plan. There are cases where this doesn't work - if the thing "over there" is actually a service rather than a couple of files. > > Most minified externally-produced javascript files are just > > downloaded verbatim off the web. > > How can we verify which ones are verbatim copies, automatically for > every release of the source package? If we don't verify, we can't > assert with confidence that some particular minified file actually > matches, in every detail of behaviour, a version for which we > distribute source. Downloading random versions is also likely to cause bugs. Downloading strict versions is susceptible to causing 404s when upstream stop bothering about obsolete versions, causing more bugs. Much better to put those dependencies into the package information. > > I agree with the sentiment that we should provide source "in Debian" > > for everything that's actually useful for our users. > > Do you agree that nobody except the recipient gets to decide what they > find useful? > > Or would you arrogate to the Debian project the power to deny the fact > that a recipient may find a Debian source package useful in itself? > > > If a dependency and a symlink exists, however, it's clear that the > > maintainer meant to say "source is over there". As I've tried to show above, "over there" is not helpful. "over there" can go away, can be updated and cannot be verified as the actual code needed by the package. "over there" doesn't help anyone fix installs on older boxes which have suddenly stopped working. > The maintainer may intend that to be true. Without independent > automated verification, we are merely guessing and hoping. How can we > verify independently that no such assertion is false? I've described > a means that is certain and simple: discard the non-source form from > the source package. Agreed, the source package needs to contain the JS in the preferred form for modification. *If* that is provided by a package at a supported version, then a symlink can be used (and a versioned dependency if the version matters as it does in some of my usecases). From upstream perspective, provide the JS in the form preferred for modification and minify during the package build. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
