On 12-08-23 at 05:15pm, Peter Samuelson wrote: > > > > Automating get-orig-source is a fine idea, but tying it to DEP-5 > > > would be unfortunate. > > [Jonas Smedegaard] > > You mean that you prefer a separate file for this info? > > > > What should be its name? What should be its syntax? > > > > ...and why start from scratch with this - or does something else > > already exist, comparable to the work of DEP-5? > > Well, two reasons not to bundle it into DEP-5 format files. First, > there may be a lot of people like me who would find value in a > config-file-driven 'get-orig-source' but who do not find any value in > maintaining debian/copyright in DEP-5 format. Tying the two together > basically means I probably won't use it, as managing my own .orig > generation seems easier than having to maintain a DEP-5 file. By > making me choose to migrate to DEP-5 in order to get the uscan > feature, you're making the feature less useful. > > Second, debian/copyright isn't a config file. I'd rather see > configuration in a config file. Perhaps the DEP-5 mindset is such > that you do see debian/copyright as a config file now, but I think its > purpose has always been documentation, not configuration. I guess you > can tell I never really cared for "literate programming".... > > Anyway, I thought I wanted a separate file, but then I remembered that > uscan already uses 'debian/watch' for configuration. The syntax of a > watch file is pretty awkward, being based on (logical) lines rather > than stanzas, and using "opts=foo=1,bar=2" instead of something like > "foo=1 bar=2", but it does seem like the right place to put additional > uscan configuration. And the watch file format can presumably be > fixed, as it is explicitly versioned.
Sounds sensible. How about, in addition to looking for excludes in DEP-5 copyright files, have uscan also support an exclude option, so that e.g. compass-susy-plugin could alternatively have this debian/watch file: version=4 opts=dversionmangle=s/\~dfsg.*// \ exclude="docs/source/fonts/* \ docs/source/javascripts/jquery-1.7.1.min.js \ docs/source/javascripts/modernizr-2.5.3.min.js" \ https://github.com/ericam/susy/tags .*/tarball/v?(\d[\d\.]+) > > > Unrelated: when I've repacked tarballs, I add a file > > > "README.Debian-tarball" to the top level source directory, > > > explaining what I did. Nobody ever suggested this to me, it just > > > seems like common sense that information about the new tarball > > > should be, well, in the new tarball. Not just in the .diff.gz. > > > > Nowadays such info is commonly put into README.source > > I know, but that's typically not in the orig.tar.gz. If someone grabs > foo_1.0+dfsg.orig.tar.gz by itself, I think it is useful to have a > README in there that explains how it is different from an upstream > foo-1.0.tar.gz. > > Hence if you're going to automate repacking, I just wanted to suggest > generating a README file to put into the repacked tarball. And as I > said, I haven't heard of anyone else doing this, so perhaps I'm the > only one who thinks it makes sense. Sorry, I missed the detail of it being in the tarball. I find adequate the common practice of renaming the tarball (and then documenting the why it was done externally from the tarball), so let's just agree to disagree on this one :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
