On Mon, Jul 7, 2014 at 5:39 AM, Karanbir Singh <mail-lists at karan.org> wrote: > On 07/07/2014 10:36 AM, Nico Kadel-Garcia wrote: >> On Mon, Jul 7, 2014 at 5:01 AM, Karanbir Singh <mail-lists at karan.org> wrote: >>> hi, >>> >>> given that srpms contain upstream tarballs, in most cases directly >>> linked from upsream; I wonder if its worth while setting up a service >>> that can track git commits, extract the urls for our lookaside tarballs >>> and compare them with the upstream projects's release tarballs. >>> >>> this would be a great addition to the ci.dev.centos.org infra, and could >>> add another data point to the 'can-we-trust-this' mindset. >>> >>> - KB >> >> When it works, it could be useful for verification of the source >> tarballs. The difficulty I see is that some of the published Source >> URL's are transient. As they become even slightly out of date, many >> projects move aside older versions to an "archive" subdirectory, or >> re-arrange their websites at whim. I ran into this with Nagios last >> year, and software that installs Nagios from tarballs. >> >> So it's potentially useful, but there's no guarantee that those URL's >> are valid for even 5 seconds after the original SPEC file was written. > > would be great to find out how many are. > > we could potentially setup cache's - and ensure that there are other > people who also run the same checks, so its not having to trust just a > single source. This looks like a very hairy to maintain and impossible to predict the requirements for project. Some repositories, like CPAN for perl modules, are very good about maintaining old locations. Other utilities like "subversion"? Historically not so good, they've relocated repos a few times. So has Samba, when they switched from 'http://' to 'https://' and 'wget' based operations started failing due to redirects. Other source bundles are based on tarballing or zipping up git exports, and that's just.... *fascinating* to try and maintain veracity with. Red Hat may be very good about this upstream for what winds up in the direct CentOS packages. I've had problems with it for EPEL packages, which are often less mainstream. You'd need to maintain some kind of separate cross referenced lookup form, constantly being upgraded and inevitably out of date.