Re: Bug#466550: Pristine source from upstream VCS repository
Russ Allbery wrote:
> Bernd Zeimetz <bernd@bzed.de> writes:
>
>> No, please don't just add another watch file just for the sake of it,
>> using these files is more or less like living in the last
>> century. People are able to get the current source from the Debian pool,
>> if that is not enough for them, they should be old enough to be able to
>> click on the upstream homepage link in the package's description and get
>> the source.
>>
>> A lot of people, including myself, prefer to pull form the upstream vcs
>> directly, and work on top of that, using git for example. Using uscan to
>> retrieve the exact version is often impossible, as it's not trivial to
>> get a tarball from a specific upstream branch, tag or ref.
>>
>> I think the way Debian should go is to tell people that they should
>> clone the developer's git ([.. insert your favourite dvcs here ...])
>> repository and work with it, probably requiring to explain how working
>> with the repository works, which branches are used for what, and so
>> on. At least that would fit *todays* way of handling packages, at least
>> for a lot of people.
>
> Hm, I think I disagree with most of this.
>
> First, I think this new habit (which you don't mention directly but
> somewhat allude to) of not making stable formal releases is a very bad one
> and I would strongly encourage any of my upstreams to not go down that
> path.
I know that some upstream go this way, and I'm not happy about it - but if you
have a sane upstream, there's no problem to import a tag or branch into git (or
whatever you prefer), while keeping the whole development history makes it
*MUCH* more easy to bisect bugs, to release experimental snapshots or just to
retrieve a diff you'd like to add as patch.
> On the topic of finding the current upstream release, I definitely don't
> agree with the idea that the home page link solves this problem. Some
> upstreams have extremely bizarre release processes, poor home pages, no
> real home page at all, or make it difficult to figure out just where the
> source is at. Having a watch file that embeds all of the packager's
> existing knowledge about how to find the upstream release is very
> valuable.
> Also, I think you're underestimating the utility of being able to find
> exactly the tarball that was used for generating a given Debian package.
> It allows independent verification of the package in the archive (useful
> in some security scenarios), and it's very important for package
> sponsorship where one should not trust the orig.tar.gz provided by the
> sponsoree unless you already know the sponsoree well.
True, but on the other side, if you and upstream are using git, it is not hard
to verify that the upstream source is still fine. Being able to download a
tarball for sponsoring via a watch file makes my life as sponsor much more easy,
indeed - but I still don't see a reason why we need a second watch file to
retrieve the current tarball. Either the original tarball is in the archive, or,
if it was repackaged, there's no chance to retrieve it with the same md5sum
again. If you're able to find the current tarball by using the normal watch file
and trying to match for the right version, that's fine, but the idea of having a
second watch file is still insane imho.
Cheers,
Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
Reply to: