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

Re: Bug#466550: Pristine source from upstream VCS repository



On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
> >>         Given that we already have a tool that can download upstream
> >>  sources, with or without mangling, and can be used by facilities
> >>  outside of the unpacked Debian source package to determine if there was
> >>  new versions and to download unmangled versions, is there any need to
> >>  retain the get-orig-source target at all?

> > I have get-orig-source targets that verify the upstream detached gpg
> > signatures before repacking the tarballs.  Is there a way to do that with
> > uscan?

>         There is no limit on what your user specified script can
>  do. Given a version number, you can still download the hash and test
>  it. No sweat.

So I have to duplicate information (the upstream URL) between the watch file
and the script?  Seems like it's better to just continue using
get-orig-source then.

> >> I mean, this seldom implemented target is duplicating an existing and
> >> widely used facility in Debian; and removing the target from the policy
> >> will advance the laudable goal of stripping the policy of cruft.

> > Well, I doubt more people are using uscan mangling than are using
> > get-orig-source, really; so I don't think that facility is "widely used".

>         There are far many more watch files in packages than there are
>  get-orig-source targets in rules files, so yes, uscan is far more
>  widely used. As I said elsewhere in this thread, mangling is not widely
>  enough automated to say anything one way or the other about practices
>  followed. 

It certainly is possible to say which of the two possible processes for
mangling is more prevalent by examining the archive.

$ cd /srv/lintian.debian.org/laboratory/source
$ find . -mindepth 3 -maxdepth 3 -name rules | xargs grep -l get-orig-source | wc -l
752
$

There are many more watch files than that, of course, but how many of them
include non-default actions?  I'm pretty confident that it doesn't approach
5% of the archive, even without subjecting gluck to a script to parse all
the watch files to check this.

>         I would not be against a recommendation in policy to implement
>  direct-from-vcs  upstream tarballs to be created vbia get-orig-source,
>  and everyone else just use debian/watch and debian/urepack files.

The (as-yet-unrealized) benefit of having this defined in policy is to give
developers other than the maintainer a simple, standard way to grab the new
upstream source of a package.  Doesn't "try debian/rules get-orig-source,
and if that doesn't exist, try uscan instead" fall short of "simple"?

(This is basically the status quo, so it's not a tragedy if we don't correct
it - but if we're going to amend policy here anyway, surely it would be good
for the outcome to be a policy definition that meets this standard.)

On Fri, Mar 13, 2009 at 10:38:35AM -0500, Manoj Srivastava wrote:

>         Let me make a case here for the get-the-latest work flow, but
>  before I do so, I would like to state that the relative popularity of
>  the work-flow ought not to be relevant when making policy: technical
>  policy should not get in the way of even a minority work-flow without
>  sound and compelling reasons to select one method or the other (usually
>  this clause gets called in for integration issues).

Popularity speaks to whether developers find it useful.  We shouldn't be
codifying requirements into Policy if it doesn't actually benefit us to
standardize on them.  But if there is a benefit from having all packages
behave the same way - "integration issues", as you say - that should be
weighed against incompatible minority workflows.

I certainly do think that the inclusion of get-orig-source in Policy serves
no purpose *but* to provide a consistent interface that developers can rely
on.  So while we should try to minimize the disruption of maintainers'
existing workflows, if this belongs in Policy at all (which I believe
ultimately it does), then that trumps the fact that some packages will need
to change in order for their maintainers to continue using their preferred
workflow.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org


Reply to: