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
On Mon, Jul 7, 2014 at 5:01 AM, Karanbir Singh mail-lists@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.
On 07/07/2014 10:36 AM, Nico Kadel-Garcia wrote:
On Mon, Jul 7, 2014 at 5:01 AM, Karanbir Singh mail-lists@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.
On Mon, Jul 7, 2014 at 5:39 AM, Karanbir Singh mail-lists@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@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.
On 07/07/2014 11:31 AM, Nico Kadel-Garcia wrote:
You'd need to maintain some kind of separate cross referenced lookup form, constantly being upgraded and inevitably out of date.
given the churn rate for centos tarballs, are you sure ? when i tried this last ( was in CentOS-5 days ), it didnt any maint really. you just need to trust the source once, and handle exceptions ( of which there were very few ).
- KB
On Mon, Jul 7, 2014 at 6:34 AM, Karanbir Singh mail-lists@karan.org wrote:
On 07/07/2014 11:31 AM, Nico Kadel-Garcia wrote:
You'd need to maintain some kind of separate cross referenced lookup form, constantly being upgraded and inevitably out of date.
given the churn rate for centos tarballs, are you sure ? when i tried this last ( was in CentOS-5 days ), it didnt any maint really. you just need to trust the source once, and handle exceptions ( of which there were very few ).
- KB
Maybe not constantly. A lot of my RPM building lately has been with EPEL packages, which are much more likely to churn than the more stable core OS components at RHEL and CentOS. I held up Samba and Subversion as specific examples I'd personally encountered. I publish backports of current releases for RHEL 6 for those over at github.com.
-
Karanbir Singh -
Nico Kadel-Garcia