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

Re: my suggestion for multiple upstream tar balls



That libcatalyst-modules-perl stuff surely  deserves its own source format?
I can see some more issues with this multiple sources stuff.
Because you cannot identify a single version number you call it a native format. But making it a native format is surely against the normal Debian approach to packaging where the upstream sources are distributed along side and untouched (apart from a little standardization of the name).

gregor herrmann wrote:
On Fri, 27 Aug 2010 15:38:22 +0100, Nicholas Bamber wrote:

The obvious thing to me would seem to be to store the current versions in
debian/source/versions

This file would consist of lines of the form
URL space version-number  new-line.

Take a look at libcatalyst-modules-perl, there's something similar
(tarballs/packages.cfg + scripts)
Although human readable and part of the packaging source code, it
would be maintained entirely by uscan and driven by the watch file.
uscan would not bother to create a versions file if there was only
one rule in the watch file and the version number in
debian/changelog made sense to it.

uscan integration sounds nice.

Even nicer would be to use the multi-tarball feature of source format
v3, but TTBOMK svn-buildpackage/-inject/-upgrade don't handle it yet.

In any case, improvements to this multi-dist packages would be much
appreciated, currently they are a pain to deal with.

Cheers,
gregor


begin:vcard
fn:Nicholas Bamber
n:Bamber;Nicholas
org:Periapt Technologies
email;internet:nicholas@periapt.co.uk
x-mozilla-html:FALSE
url:http://www.periapt.co.uk
version:2.1
end:vcard


Reply to: