[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Enabling uscan to simply remove files from upstream source

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:

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

Attachment: signature.asc
Description: Digital signature

Reply to: