FPC ticket for building for multiple versions of a language stack?

[Orion Poplawski]

On 09/29/2015 02:36 AM, Nick Coghlan wrote:
> On 28 September 2015 at 17:18, John Dulaney <jdulaney at fedoraproject.org> wrote:
>> ----------------------------------------
>>> Date: Mon, 28 Sep 2015 15:18:00 +1000
>>> Subject: FPC ticket for building for multiple versions of a language stack?
>>> From: ncoghlan at gmail.com
>>> To: env-and-stacks at lists.fedoraproject.org
>>>
>>> Hi folks,
>>>
>>> My Google-fu is failing me, so I'm asking to see if anyone else has
>>> the relevant link: I recall seeing a proposal a while back (from
>>> Slavek, IIRC) to support running a spec file multiple times with a
>>> different target location each time (but still having a default
>>> location used in a "normal" RPM build).
>>>
>>> This wasn't about SCLs, it was about situations like building for
>>> python 2 + python 3 + pypy + jython, or for the multiple Python 3
>>> stacks in EPEL. The general idea was that packaging for multiple
>>> runtimes shouldn't be as difficult as it currently is.
>>>
>>> Cheers,
>>> Nick.
>>
>>
>> Well, why run it multiple times, and instead just set up your spec file
>> to build different sub-packages against each stack you want to support,
>> like what is already done for py2 and py3?
>
> Because the status quo means that if we have (say) 5000 Python
> packages, and we want to support a parallel Python stack for PyPy, we
> have to modify 5000 spec files. Ditto for Jython and IronPython (and
> don't forget to multiple by 2 for PyPy3, and eventually Jython3 and
> IronPython3).
>
> This doesn't make any sense when "<runtime> -m pip install --no-deps
> <package_name>" works to install any Python package into the
> appropriate location for the given runtime.
>
> If we decouple the two operations and have the spec file merely say
> "Here is how to install this module for a given Python runtime", then
> we can separate out the packaging of the module for the default Python
> runtime, and rebuilding it for alternate runtimes.
>
> The ideal end state then becomes being able to ship all of the Python
> packages with %check sections that pass with that runtime for every
> Python runtime available in Fedora.
>
> The alternative in the meantime is to just use Fedora to manage the
> runtimes themselves, and use the Python specific module management
> tooling on top of that, which is exactly what most developers are now
> doing.
>
>> Of course, I haven't seen what
>> you are referring to, so I may be missing out on something brilliant.
>
> Slavek's idea was to do this at the RPM level, by introducing loops
> into spec files: http://rpm.org/ticket/883
>
> My inclination is to favour a more SCL style approach, where the
> definition of the runtimes to build for is defined at the distribution
> level, rather than in the individual packages.
>
> Cheers,
> Nick.
>

We're working on something somewhat similar here: 
https://fedorahosted.org/fpc/ticket/567

The problem I have with at the moment is trying to automatically 
generate the proper %files sections.  Perhaps if the install could 
generate a manifest.

But yeah, the SCL/distribution approach has a fair amount of appeal as 
well, as long as the proper namespacing is done which gets tricky.  I 
had an idea a while back about somehow having different repos get put 
into different namespaces automatically which I still think would be 
worth pursuing.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com