Re: [eigen] Providing non-tag downloads over BitBucket

[Raphael Kubo da Costa <rakuco@xxxxxxxxxxx>]

Benoit Jacob <jacob.benoit.1@xxxxxxxxx> writes:

> 2012/1/1 Raphael Kubo da Costa <rakuco@xxxxxxxxxxx>:
>> Comparing FreeBSD's own copy of the 2.0.16 tarball [1]
>
> How was it generated?

In the port's Makefile, we specify where the tarball should be
downloaded from, and at some point (probably when binary packages are
generated, but I'm not 100% sure) the FreeBSD servers download the
specified tarball and store a local copy (it is usually used as a last
download resort in case the main download server goes down etc).

>> with the one
>> currently being provided by BitBucket [2], it looks like only the
>> tarball name (and the directory inside it) have changed from
>> eigen-eigen-2.0.16 to eigen-eigen-<hash of the commit which the tag
>> points to>. diff shows no difference in the actual contents.
>
> of course that's the case: tagging a changesets only modifies the
> special hgtags file.
>
> how is that a problem?

The problem is that we specify in the port that eigen's tarball has a
certain name, directory structure and checksum, which should all match
when the port is built (FreeBSD could be considered a source-based
distribution like Gentoo). But then BitBucket for some reason changes
the tarball's name, top directory name and, consequently, its checksum,
so building eigen from FreeBSD's ports tree fails. The packagers then
need to check why the tarball has changed (the server could have been
compromised, the source code could have been tampered etc) and, if it is
the case, adjust the port accordingly again.

>> As a packager, I would appreciate if Eigen started providing
>> "real" download tarballs in the Downloads section in BitBucket (like
>> other projects do) to prevent this kind of issue -- I guess tarballs
>> which are not created automatically do not risk being changed by
>> BitBucket.
>
> That would incur more manual work when doing releases and would
> increase our reliance on bitbucket, so we would need a good reason to
> do that.

I agree that it may incur more manual work, but I didn't understand why
the reliance on bitbucket would be increased (the tarball could be
hosted anywhere you prefer).

Thanks.