Building and publishing Software Collections from COPR or Koji?

[Nick Coghlan]

On 23 June 2015 at 17:12, Bohuslav Kabrda <slavek at redhat.com> wrote:
> ----- Original Message -----
>> On 20 June 2015 at 03:07, Honza Horak <hhorak at redhat.com> wrote:
>> > On 06/02/2015 04:38 AM, Nick Coghlan wrote:
>> >> The context is that seeing https://github.com/squeaky-pl/portable-pypy
>> >> reminded me that I'd been meaning to ask for a while if anyone looked
>> >> at turning the PyPy and PyPy3 packages for Fedora/EPEL into sofware
>> >> collections for softwarecollections.org.
>> >
>> > I'm not that familiar with python packaging of PyPy packages, is it
>> > possible
>> > to do it fully automatically? Or we need to do it semi-automatically for
>> > the
>> > first time and then we can just rebase to newest versions automatically?
>>
>> I don't know either, unfortunately - digging into the PyPy packages is
>> one of those things that's never made it to the top of my personal
>> priority list :(
>
> So, this was one of my goals when I was working on the Python stack, but I never really had the time to push this.
> I actually wanted to build these two stacks in Fedora proper, e.g. not as SCL but as part of the base system. The problem was that for every interpreter we'd need to add another subpackage to every Python package (well, for every package that we'd want to work with that interpreter). So I took a step back and opened an issue for dynamic generation of RPM subpackages [1] which would pretty much solve our problem. Unfortunately noone from RPM upstream has reacted and I haven't had the time to push this because of all the work on Python 3 as Default.
> If anyone is interested in this, please leave a comment at the upstream RPM issue and I can start pushing this, since I've been having a bit of spare time lately.

Interesting. The fact that you're using loops makes we wonder if we
could solve the problem at a different layer: what if we had the
notion of "multistack" RPMs that were vaguely analagous to SCLs, but
built normal system RPM packages for each variant rather than
squirreling them away in /opt.

At the RPM level, this could just be a single new declarative field:

   %multistack python_interpreter python3 python2 jython pypy

The first entry in the list would be processed by default, but rpm
would gain a way to tell it to build for one of the other stacks
instead.

Doing things selectively for different stacks could just use existing
%if directives as you do in your example, but the need for the inline
looping directive could go away.

Then mock and koji could be made multistack aware, query the RPM for
the stack definitions, and build for all of them, rather than each
specfile needing to be modified in multiple places to account for new
stacks (at least those where the build process is broadly compatible
across stacks).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia