Re: Recommending get-orig-source for packages ?
On Dec 04, 2013, at 01:36 PM, Stuart Prescott wrote:
>Having uscan call "debian/rules get-orig-source" is quite difficult to do in
>a policy-compliant way (as already noted by Jakub) as the location for the
>munged tarball is different. Having uscan call a debian/repack from d/watch
>seems a little more sane only because there's no policy saying what d/repack
>must do; having uscan do the repacking itself with something like Files-
>Excluded from d/copyright is even nicer and devscripts in git can do this.
If you have a good example of a d/repack recipe, please do add it to the
LibraryStyleGuide wiki page. I just added an example d/watch for packages
which provide a tarball via PyPI (probably the majority of packages this team
touches).
>Like so many things in Debian there is more than one way to do something that
>is truly simple and for which there probably should only be one way. It would
>be nice if we didn't have more than one way of doing something as simple as
>fetching an upstream source -- it's harder for automation, it's harder for
>QA, it's harder for new maintainers and it's harder for casual bug
>squashers. Without undertaking any sort of survey of packages, my feeling is
>that the project is centralising on d/watch + uscan instead of
>get-orig-source.
One of my goals for LibraryStyleGuide and other Python-team related wiki pages
is to be opinionated about the "best" way to do things, given the multitude of
options. We may not always agree on what that best way is, but I think we all
do agree on promoting techniques that lower the barrier to packaging Python
goodness. After all, packaging is the boring part, right? :)
-Barry
Reply to: