Hi, I've been debating this all week and decided it's probably better as a community decision than just my own.
Problem: The current source rpm for origin is generated using tito on the origin git repo. The biggest problem with this is the tarball is generated on the fly and sortof encorporated into the spec file. That makes it hard for others to duplicate the src.rpm and/or make patches for it.
If I were an outsider (not on the openshift team) and making an rpm for Fedora/EPEL, I wouldn't do this. I would grab the released tarball from Github and build my spec file around that.
Solution 1: Keep things the same. Do others really care that they can't duplicate the src.rpm without tito, as long as they can recompile it?
Solution 2: Create a origin spec file that uses the tarball from Github. I've already done this. It works quite well. But it does involve some manual spec file editing.
Troy p.s. I am totally fine either way. The only reason I've been debating this is because I keep having issues with tito making the whole src.rpm.
On Thu, Sep 15, 2016 at 5:55 PM, Troy Dawson tdawson@redhat.com wrote:
Hi, I've been debating this all week and decided it's probably better as a community decision than just my own.
Problem: The current source rpm for origin is generated using tito on the origin git repo. The biggest problem with this is the tarball is generated on the fly and sortof encorporated into the spec file. That makes it hard for others to duplicate the src.rpm and/or make patches for it.
If I were an outsider (not on the openshift team) and making an rpm for Fedora/EPEL, I wouldn't do this. I would grab the released tarball from Github and build my spec file around that.
Solution 1: Keep things the same. Do others really care that they can't duplicate the src.rpm without tito, as long as they can recompile it?
Personally, I like this approach since it integrates with rhpkg/fedpkg very well. I'm not sure if CentOS has a similar tool that provides dist-git alongside koji, but I like the idea of being able to leverage the same spec file for all builds.
That said, I do wonder if providing a tool that could "convert" the tito managed spec file to one that can be run outside of tito would be beneficial.
Solution 2: Create a origin spec file that uses the tarball from Github. I've already done this. It works quite well. But it does involve some manual spec file editing.
Troy p.s. I am totally fine either way. The only reason I've been debating this is because I keep having issues with tito making the whole src.rpm.
cc'ing Devan Goodwin, since he knows a bit about tito. I'm also cc'ing Adam Miller, since I know he is packaging OpenShift Origin for Fedora.
Here's the problem I'm encountering. Dist-git is great, and probably where we should be targeting. It has a lookaside fit the tarballs and such. Why is this not good enough? Can the lookaside be adjusted to use the same tarballs? I wrote something back when I was working on GoOSe that would have been able to be flexible enough for this concept.
My knowledge of Tito is not enough to say for sure, but it should be able to either pull a tarball, or modify the spec in a way to deal with those changes.
Essentially, I don't see why the process can't accommodate the automation bits, but also make it easy for a contributor. In fact, maybe downloading the tarball, then telling Tito might be a good choice.
My suggestion here is to update Tito to accommodate an already existing tarball, either downloaded it in the lookaside cache. In the meantime, don't change your process.
Thoughts?
On Sep 15, 2016 20:51, "Jason DeTiberus" jdetiber@redhat.com wrote:
On Thu, Sep 15, 2016 at 5:55 PM, Troy Dawson tdawson@redhat.com wrote:
Hi, I've been debating this all week and decided it's probably better as a community decision than just my own.
Problem: The current source rpm for origin is generated using tito on the origin git repo. The biggest problem with this is the tarball is generated on the fly and sortof encorporated into the spec file. That makes it hard for others to duplicate the src.rpm and/or make patches for it.
If I were an outsider (not on the openshift team) and making an rpm for Fedora/EPEL, I wouldn't do this. I would grab the released tarball from Github and build my spec file around that.
Solution 1: Keep things the same. Do others really care that they can't duplicate the src.rpm without tito, as long as they can recompile it?
Personally, I like this approach since it integrates with rhpkg/fedpkg very well. I'm not sure if CentOS has a similar tool that provides dist-git alongside koji, but I like the idea of being able to leverage the same spec file for all builds.
That said, I do wonder if providing a tool that could "convert" the tito managed spec file to one that can be run outside of tito would be beneficial.
Solution 2: Create a origin spec file that uses the tarball from Github. I've already done this. It works quite well. But it does involve some manual spec file editing.
Troy p.s. I am totally fine either way. The only reason I've been debating this is because I keep having issues with tito making the whole src.rpm.
cc'ing Devan Goodwin, since he knows a bit about tito. I'm also cc'ing Adam Miller, since I know he is packaging OpenShift Origin for Fedora.
-- Jason DeTiberus
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Sep 16, 2016 at 12:43 PM, Clint Savage herlo1@gmail.com wrote:
Here's the problem I'm encountering. Dist-git is great, and probably where we should be targeting. It has a lookaside fit the tarballs and such. Why is this not good enough? Can the lookaside be adjusted to use the same tarballs? I wrote something back when I was working on GoOSe that would have been able to be flexible enough for this concept.
My knowledge of Tito is not enough to say for sure, but it should be able to either pull a tarball, or modify the spec in a way to deal with those changes.
Essentially, I don't see why the process can't accommodate the automation bits, but also make it easy for a contributor. In fact, maybe downloading the tarball, then telling Tito might be a good choice.
My suggestion here is to update Tito to accommodate an already existing tarball, either downloaded it in the lookaside cache. In the meantime, don't change your process.
Thoughts?
+1, spot on of what I was thinking as well
On Sep 15, 2016 20:51, "Jason DeTiberus" jdetiber@redhat.com wrote:
On Thu, Sep 15, 2016 at 5:55 PM, Troy Dawson tdawson@redhat.com wrote:
Hi, I've been debating this all week and decided it's probably better as a community decision than just my own.
Problem: The current source rpm for origin is generated using tito on the origin git repo. The biggest problem with this is the tarball is generated on the fly and sortof encorporated into the spec file. That makes it hard for others to duplicate the src.rpm and/or make patches for it.
If I were an outsider (not on the openshift team) and making an rpm for Fedora/EPEL, I wouldn't do this. I would grab the released tarball from Github and build my spec file around that.
Solution 1: Keep things the same. Do others really care that they can't duplicate the src.rpm without tito, as long as they can recompile it?
Personally, I like this approach since it integrates with rhpkg/fedpkg very well. I'm not sure if CentOS has a similar tool that provides dist-git alongside koji, but I like the idea of being able to leverage the same spec file for all builds.
That said, I do wonder if providing a tool that could "convert" the tito managed spec file to one that can be run outside of tito would be beneficial.
Solution 2: Create a origin spec file that uses the tarball from Github. I've already done this. It works quite well. But it does involve some manual spec file editing.
Troy p.s. I am totally fine either way. The only reason I've been debating this is because I keep having issues with tito making the whole src.rpm.
cc'ing Devan Goodwin, since he knows a bit about tito. I'm also cc'ing Adam Miller, since I know he is packaging OpenShift Origin for Fedora.
-- Jason DeTiberus
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-
Ari LiVigni -
Clint Savage -
Jason DeTiberus -
Troy Dawson