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