Mailinglist Archive: opensuse-ruby (83 mails)

< Previous Next >
Re: [opensuse-ruby] Revised gem packaging
  • From: Sascha Peilicke <saschpe@xxxxxxx>
  • Date: Tue, 06 Nov 2012 12:50:02 +0100
  • Message-id: <5098F96A.10503@suse.de>
On 11/06/2012 12:43 PM, Adam Spiers wrote:
Klaus Kaempf (kkaempf@xxxxxxx) wrote:
* Adam Spiers <aspiers@xxxxxxxx> [Nov 05. 2012 19:54]:
Klaus Kaempf (kkaempf@xxxxxxx) wrote:
* Stephan Kulow <coolo@xxxxxxx> [Nov 05. 2012 14:41]:

No, the suffix is only there to avoid clashes between two .rpm files.
You can't have rubygem-<gem> twice in the build service.

Where can I file feature (bug ?) reports against the build service ?
(SCNR!)

Then I'd advocate to keep the version suffix in the build service
package name (to work around the above mentioned build service bug)

I don't understand what the bug is? It already seems to work fine
in the example you cited:


https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem

https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The 'bug' is that I need to create two different 'package' entries in
OBS. I'd rather see OBS support multiple versions for a package natively.

Presumably you mean a single package containing multiple spec files,
rather than a single spec file containing multiple versions? The
latter sounds like a disaster. But the former poses several
challenges too, e.g. how would 'osc build' know which to build?
Please note that this is done quite often, e.g. to split out doc
packages that would otherwise pollute the build log/time/requirements of
the base package/spec. "osc build" AFAICS has magic to use the spec file
that matches the OBS package name (if there is one), "osc vc" does not
(yet) and needs you to explicitly mention the changes file you want to
touch (you can do the same with osc build, though).

And I
can't really see any advantages to this - none of the files inside the
project could be shared, so your current approach of using
sblim-sfcb-$something to provide clean separation of sources / spec /
changes / patches etc. seems to make the most sense to me.



--
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend├Ârffer HRB 16746 (AG N├╝rnberg)

< Previous Next >
List Navigation
Follow Ups