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

Re: Enabling uscan to simply remove files from upstream source

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

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

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.


Reply to: