Hi, I checkout git@github.com:openSUSE/open-build-service.git and I am looking for spec file for obs-server itself.
I discovered: dist/obs-server.spec but it have: Version: 2.3.95_27_gc802e5a While latest stable version is 2.4.3-6.1.
While I can extract that spec file from src.rpm, I'm more interested in what is location is upstream source?
Am Dienstag, 2. Juli 2013, 14:52:03 schrieb Miroslav Suchý:
Hi, I checkout git@github.com:openSUSE/open-build-service.git and I am looking for spec file for obs-server itself.
I discovered: dist/obs-server.spec but it have: Version: 2.3.95_27_gc802e5a While latest stable version is 2.4.3-6.1.
While I can extract that spec file from src.rpm, I'm more interested in what is location is upstream source?
Currently in our OBS:Server:2.4 and OBS:Server:Unstable projects in build.opensuse.org.
But I can update it in git as well ...
On 02.07.2013, at 15:57, Adrian Schröter adrian@suse.de wrote:
Am Dienstag, 2. Juli 2013, 14:52:03 schrieb Miroslav Suchý:
Hi, I checkout git@github.com:openSUSE/open-build-service.git and I am looking for spec file for obs-server itself.
I discovered: dist/obs-server.spec but it have: Version: 2.3.95_27_gc802e5a While latest stable version is 2.4.3-6.1.
While I can extract that spec file from src.rpm, I'm more interested in what is location is upstream source?
Currently in our OBS:Server:2.4 and OBS:Server:Unstable projects in build.opensuse.org.
But I can update it in git as well …
They doesn't update spec file in git because it updated directly in obs package.
On 07/02/2013 02:57 PM, Adrian Schröter wrote:
But I can update it in git as well ...
It would be nice if it can be updated in git as well. Because then I can track the changes. Yes, I know that osc can track version of spec as well. But it really does not help with finding e.g. why BuildRequires: perl-XML-Parser +BuildRequires: xorg-x11-server PreReq: /usr/sbin/useradd /usr/sbin/groupadd happened. Because osc could not 'blame', while git can.
I know that updating something on two locations sucks, so I prepared OBS releaser for Tito [1]. Which can help you to pack sources and spec and send it to OBS. I will elaborate on this, once this PR will be accepted and new version released.
[1] https://github.com/dgoodwin/tito/pull/91
Am Freitag, 2. August 2013, 11:47:57 schrieb Miroslav Suchý:
On 07/02/2013 02:57 PM, Adrian Schröter wrote:
But I can update it in git as well ...
It would be nice if it can be updated in git as well. Because then I can track the changes.
Okay, so far it was just much easier for me to maintain it directly in OBS. But I have changed this now to take the spec file from git, so it will become easier for use to work on that.
Just the version will still be updated by the
Yes, I know that osc can track version of spec as well. But it really does not help with finding e.g. why BuildRequires: perl-XML-Parser +BuildRequires: xorg-x11-server PreReq: /usr/sbin/useradd /usr/sbin/groupadd happened. Because osc could not 'blame', while git can.
I know that updating something on two locations sucks, so I prepared OBS releaser for Tito [1]. Which can help you to pack sources and spec and send it to OBS. I will elaborate on this, once this PR will be accepted and new version released.
hm, I have not looked at it directly, but I personally do like a server side hosted approach, like the source services better. In that way it is documented how to update sources while looking at it and it is reproducable and can be verified.
On 08/05/2013 03:38 AM, Adrian Schröter wrote:
Am Freitag, 2. August 2013, 11:47:57 schrieb Miroslav Suchý:
On 07/02/2013 02:57 PM, Adrian Schröter wrote:
But I can update it in git as well ...
It would be nice if it can be updated in git as well. Because then I can track the changes.
Okay, so far it was just much easier for me to maintain it directly in OBS. But I have changed this now to take the spec file from git, so it will become easier for use to work on that.
A related story, well more or less related ...
At SGI, we also faced this "design" where we absolutely have metadata ( _service, spec file, etc ... ) controlled via an SCM, ie GIT. We did it by creating a new "obs service" script responsible for: - extracting a "_spec" file froim the tarball, as part of the standard source tarball. - fan out "_spec" file onto several targets distributions ( sles11sp2, sles11sp3, rhel6, rhel7 ) while proceeding to the kind of adjustments you showed below. Oi course, "_spec" fans out as product-sles11sp2.spec, product-sles11sp3.spec, etc ...
That's how we could simplify the fact a single spec file ( _spec ) could be used against several distributions without clobbering it with bazillions of "%if vendor/vendor_release" statements. In fact, we just substitute, on a target distro basis, the appropriate "BuildRequires" and "Requires", simply using "sed". Iow, we don't require Developers to maintan a specfile-for-each-distro. Only one is used ( "_spec" ) and a generic sed-based substitution is used.
In short, SGI Developers just have to 'git commit' _service, _spec, _pkg ( listing the distros this package should build against ) and a "_prepare" script specifying instructions to extract the source from the tarball and how "_spec" is fanned out. As a result, we could spin a new OBS appliance from scratch without worrying about any "OBS" history since it's all via "GIT".
Yes, I know that osc can track version of spec as well. But it really does not help with finding e.g. why BuildRequires: perl-XML-Parser +BuildRequires: xorg-x11-server PreReq: /usr/sbin/useradd /usr/sbin/groupadd happened. Because osc could not 'blame', while git can.
I know that updating something on two locations sucks, so I prepared OBS releaser for Tito [1]. Which can help you to pack sources and spec and send it to OBS. I will elaborate on this, once this PR will be accepted and new version released.
hm, I have not looked at it directly, but I personally do like a server side hosted approach, like the source services better. In that way it is documented how to update sources while looking at it and it is reproducable and can be verified.
On 08/26/2013 09:26 PM, Michel Bourget wrote:
That's how we could simplify the fact a single spec file ( _spec ) could be used against several distributions without clobbering it with bazillions of "%if vendor/vendor_release" statements.
Interesting. I have quite opposite experience. I.e. maintaining multiple spec files does not worked well, while one spec file with bazillions of %if worked fine. #justsaying
Am Dienstag, 27. August 2013, 09:44:56 schrieb Miroslav Suchý:
On 08/26/2013 09:26 PM, Michel Bourget wrote:
That's how we could simplify the fact a single spec file ( _spec ) could be used against several distributions without clobbering it with bazillions of "%if vendor/vendor_release" statements.
Interesting. I have quite opposite experience. I.e. maintaining multiple spec files does not worked well, while one spec file with bazillions of %if worked fine. #justsaying
even better is to have one spec file and avoid %if statements but use generic macros which can be distro specific ;)
On 08/27/2013 09:55 AM, Adrian Schröter wrote:
even better is to have one spec file and avoid %if statements but use generic macros which can be distro specific
Yes :), but it only works to certain limit. E.g. sysvinit vs. systemd, Soft deps vs. distribution, which can not handle soft deps. etc.
buildservice@lists.opensuse.org
-
Adrian Schröter -
Kanstantsin Shautsou -
Michel Bourget -
Miroslav Suchý