[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-24 at 11:28am, Andreas Tille wrote:
> On Fri, Aug 24, 2012 at 10:59:10AM +0200, Jonas Smedegaard wrote:
> > > 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.
> 
> Uhmm, that's the first case in my memory that you drifted away from one
> of your reasonable proposals. ;-)

Sorry if I was too brief: sensible, even if I do not agree.

I find the argument sensible that not all are comfortable with using 
machine-readable copyright file for expressing information to be 
readable by machines.

I am still a big fan of DEP-5.  I won't use an eventual alternative 
uscan syntax.

...or, since it was later pointed out that "uscan" is narrowly for 
scanning for upstream source, not repackaging it, such alternative newly 
invented syntax could instead be stuffed into a brand new 
debian/exclude-from-uscan or whatever.



> > 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\.]+)
> 
> While I suggested in my initial proposal a separate file (not actually 
> debian/watch but this solution seems to be comparable to a separate 
> file) I think we are lacking the feature of documentation what was 
> removed and what not and from my (and Jonas' previous point of view 
> debian/copyright is a very good place to do this).

Yes, I am perfectly aware of that.  I was simply trying to play along 
with the "DEP-5 is wrong, uscan is adequate" mindset.

I'll leave it to fans of that mindset to drive it further...


> > > 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 :-)
> 
> In my practice (several years ago) I used the *.orig.tar.gz files from 
> a Debian mirror to build my own system inside $HOME on a HP-UX 
> machine. The advantage of using the Debian mirror was that you find 
> everything you need in one place.  For this purpose it would have been 
> helpful to have a short notice what was changed right inside the 
> changed tarball. I admit that is a rare use case these days - but it 
> might be nice anyway.

I find that it is an argument of putting the notice inside the box 
instead of aside it (in the debian tarball/diff).  Good luck driving 
that further.


 - 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: