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
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.
Peter
Reply to: