Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
On Fri, 3 Apr 2009, Raphael Geissert wrote: One additional thought: We store packaging Vcs and upstream homepage in debian/control. What about storing upstream Vcs there as well and teach uscan to look there as well. Just a rough thought. And do what with it? how will it know what it should look for? that's why all that information is in and belongs to the watch files. Why not teaching uscan reading uscan watch *and* control file. IMHO the upstream VCS might be useful for other tools than uscan as well and duplicating information is bad. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
Andreas Tille wrote: On Fri, 3 Apr 2009, Raphael Geissert wrote: One additional thought: We store packaging Vcs and upstream homepage in debian/control. What about storing upstream Vcs there as well and teach uscan to look there as well. Just a rough thought. And do what with it? how will it know what it should look for? that's why all that information is in and belongs to the watch files. Why not teaching uscan reading uscan watch *and* control file. What's the benefit? what would uscan do with the control file? how will it know the pattern it should use? IMHO the upstream VCS might be useful for other tools than uscan as well and duplicating information is bad. Uscan needs extra information to do something useful with a URI which, if embedded in the control file, would confuse other tools or would require other tools to massage the URI before using it (in that case, why not require the other tools to obtain that information from the watch file?). And as for duplication: sure, but currently the copyright file usually mentioned where the source code was obtained from (usually upstream's home page) and the control file usually contains the home page as well; that's duplication (triplication in case it is the same base address the watch file uses). Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
Ben Finney wrote:
Raphael Geissert atomo64+deb...@gmail.com writes:
I planned to add support for svn in version 4 watch files (it would
be a matter of svn info svn://domain.tld/path/to/repo and some data
massaging).
But well, now that everyone is talking about it why not just tell
what is missing so that it can be addressed in version 4 watch
files?
I would like to propose a complete rethinking of the watch files.
We have several packages, which must be prepared from a VCS or
must be repckaged. ATM several people changed to use something like
$url $pattern debian /bin/sh get-orig-source-script
One can't use
$url $pattern debian /usr/bin/make debian/rules get-orig-source
because make will error out because of the unknown switch
--upstream-version.
The next propblem is, that such a script doesn't have the same purpose
as uupdate has, as the first is used to create a new tarball and the
second to apply an existing diff to the new tarball.
So I was thinking about, how this could be solved. One idea, that came
to my mind is: Why not source debian/watch by uscan? One could then
write a watch file like this:
- first declare $url $pattern and maybe debian/uupdate like in the old
watch file versions (probably this requires a new syntax, if
debian/watch is sourced by the uscan script)
- then declare a function
sub prepare_orig_tarball () {
... the arguments should be upstream-version, debian-version,
downloaded tarball name, orig-tarball name and ??? ...
... then add the commands to prepare/repack the tarball ...
}
uscan should then try, if this function exists, if not, simply download
the tarball/file specified by the pattern.
The function could simply contain a call like
/usr/bin/make debian/rules get-orig-source \
VERSION=$uvers PACKAGE=$orig_tarball
or call the already written get-orig-source script with the appropriate
arguments.
Opinions?
I'm pretty busy atm, but I would like to help fixing/improving uscan.
Regards, Daniel
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
On Fri, 3 Apr 2009, Daniel Leidert wrote: I would like to propose a complete rethinking of the watch files. We have several packages, which must be prepared from a VCS or must be repckaged. ATM several people changed to use something like $url $pattern debian /bin/sh get-orig-source-script One can't use $url $pattern debian /usr/bin/make debian/rules get-orig-source because make will error out because of the unknown switch --upstream-version. I used to work around this in my packages by providing a debian/get-orig-source script which is just called in the get-orig-source target of debian/rules. This might be a way to circumvent this specific problem (nothing against rethinking in general for sure). The next propblem is, that such a script doesn't have the same purpose as uupdate has, as the first is used to create a new tarball and the second to apply an existing diff to the new tarball. Exactly - so my suggested workaround just solves the problem of the old way of thinking. ... Opinions? Interesting. One additional thought: We store packaging Vcs and upstream homepage in debian/control. What about storing upstream Vcs there as well and teach uscan to look there as well. Just a rough thought. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
Andreas Tille wrote: [...] One additional thought: We store packaging Vcs and upstream homepage in debian/control. What about storing upstream Vcs there as well and teach uscan to look there as well. Just a rough thought. And do what with it? how will it know what it should look for? that's why all that information is in and belongs to the watch files. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
Ben Finney wrote: [...] For my purposes, I would like to be able to specify “fetch from the VCS at $URL, getting the specific working tree referenced by identifier $ID” and then the rest of what uscan does for generating an original source archive from the working tree. That's made more complex, of course, by: * the fact that the URL doesn't necessarily indicate what VCS tool is needed to interact with it (just about all of them allow an HTTP URL for public read-only access, so that's what will commonly be used here) That can easily solved, svn+http://... * the plethora of different concepts for mapping identifiers to specific working trees in different VCSen (revision-id and branches and tags, oh my!) uscan would retrieve the information (say the output of svn info svn://domain.tld/repo/) and match the rest of the pattern against the output. Whataver is specified is what would uscan would svn export. Ideally this would be predicated on the Final and Definitive Interface to All VCSen Now and Future™, but I think that might be delayed by at least a month or so. s/month/decade? Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
[No CC please] Daniel Leidert wrote: [...] I would like to propose a complete rethinking of the watch files. We have several packages, which must be prepared from a VCS or must be repckaged. ATM several people changed to use something like $url $pattern debian /bin/sh get-orig-source-script One can't use $url $pattern debian /usr/bin/make debian/rules get-orig-source because make will error out because of the unknown switch --upstream-version. Sure, that's something that could be modified in version 4 watch files. I'm thinking about a format string a-la printf. The next propblem is, that such a script doesn't have the same purpose as uupdate has, as the first is used to create a new tarball and the second to apply an existing diff to the new tarball. So I was thinking about, how this could be solved. One idea, that came to my mind is: Why not source debian/watch by uscan? One could then write a watch file like this: I'm against sourcing anything, this is far beyond the pourpose of the watch files and can be done by a specified helper script. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)
Raphael Geissert atomo64+deb...@gmail.com writes: I planned to add support for svn in version 4 watch files (it would be a matter of svn info svn://domain.tld/path/to/repo and some data massaging). But well, now that everyone is talking about it why not just tell what is missing so that it can be addressed in version 4 watch files? For my purposes, I would like to be able to specify “fetch from the VCS at $URL, getting the specific working tree referenced by identifier $ID” and then the rest of what uscan does for generating an original source archive from the working tree. That's made more complex, of course, by: * the fact that the URL doesn't necessarily indicate what VCS tool is needed to interact with it (just about all of them allow an HTTP URL for public read-only access, so that's what will commonly be used here) * the plethora of different concepts for mapping identifiers to specific working trees in different VCSen (revision-id and branches and tags, oh my!) Ideally this would be predicated on the Final and Definitive Interface to All VCSen Now and Future™, but I think that might be delayed by at least a month or so. -- \ “I don't know anything about music. In my line you don't have | `\ to.” —Elvis Aaron Presley (1935-1977) | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
