Re: Bug#466550: Pristine source from upstream VCS repository
On Wed, Mar 18 2009, Steve Langasek wrote:
> 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.
For the smallish subset of packages that have upstream hash, and
do download and check it, and who do not otherwise have to specify a
URL (I mean, the url for the tarball and the hash can not be the same,
neh?), yup, some duplication ensues. The common case is unaffected, I
think.
>> >> 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.
How many of the get-orig-source targets follow written policy
and get the latest upstream sources?
>> 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"?
While this is subjective, I think this is simple enough,
especially for the user base that is wanting sources not from
the Debian archive. Most users who can't follow "Do a, if that fails,
do B" would be satisfied with apt-get source, I would think.
Anyway, since get-orig-source is an optional target, you
_have_to try uscan, and if that fails, get-orig-source, and changing
this will ijpact 95% or so of the debian/rules, and for what benefit?
(more on this below)
> (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.
get-orig-source is optional. And rightly so, about 94% of the
packages are well served by just uscan, imposing a target that just
calls uscan is vbusy work for most packages. I would strongly oppose
any move to make get-orig-source mandatory unless better arguments are
made for utility, than just "consistent ways to get sources not in
Debian archives". That use case is not common enough to undergo a major
transition that touches most debian/rules files.
I think that the minority is to use get-orig-source as opposed
to uscan -- since you really only need anything other than uscan if you
have to mangle upstream sources, and the vary vast majority of packages
do not have to.
By this measure, if anything has to change, the upstream
mangling packages ought to be changing, and the others should just use
uscan, as normal, and not implement the optional target
get-orig-source
--
Sometimes I wonder if I'm in my right mind. Then it passes off and I'm
as intelligent as ever. -- Samuel Beckett, "Endgame"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: