On Thu, May 31, 2018 at 9:49 AM Richard W.M. Jones <rjones@redhat.com> wrote:

On Thu, May 31, 2018 at 08:53:25AM -0400, Stephen Gallagher wrote:
> Are these packages parallel-installable (and do they need to be?)

In theory, although practically it probably wouldn't be the end of the
world if they were not parallel installable (it's my understanding
that the current module proposal does not allow parallel installation
of modules).

Correct, modules right now allow parallel-*availability*, but only one stream can be installed at a time.

 

The scenario were parallel installation would be useful is something
like you want to synch between *three* machines with mutually
incompatible versions of unison, and the Fedora machine in the middle
needing both.  It's pretty obscure.

Yeah, that seems like the sort of thing we'd probably want to discourage (or if we can't discourage it, solve it by running unison in a container).

 

> It seems
> to me like this would be a FAR better solution as a module. You just have
> branches for the major/minor releases and then ship module streams for each
> one. They can be built and updated independently (rather than rebuilding
> all of them each time any of them releases an update).
>
> I can help you with this, if it's an approach you want to take.

It's worth looking at certainly.  Could you look at these two files
and tell me how they could be turned into a module?  If you look at
them side by side you can see they are very similar, probably one
derived from the other at some point in the past:

https://src.fedoraproject.org/rpms/unison213/blob/master/f/unison213.spec
https://src.fedoraproject.org/rpms/unison227/blob/master/f/unison227.spec

The cliffs notes version:

* Resurrect the 'unison' (unversioned) package name.

* Run `fedpkg request-branch 2.13 --sl="rawhide:2020-06-01"`

* Run `fedpkg request-branch 2.17 --sl="rawhide:2020-06-01"`

* Switch to the 2.13 branch

* Copy the unison213 spec in there as unison.spec and drop the pieces that change the paths to include "213".

* Push the 2.13 branch to dist-git

* `fedpkg clone modules/unison` (this will have been created as part of request-branch above unless you pass --no-auto-module)

* Switch to the 2.13 branch (also auto-created)

* Create the modulemd file. This can be done easily with 'fedmod' (currently in updates-testing).

- `fedmod fetch-metadata` (takes a couple minutes the first time)

- `fedmod rpm2module unison213 > unison.yaml` (Filename must match the dist-git module name plus .yaml, similar to how RPMs have to match the specfile name)

- Fix the places where the generated file includes "213" (this step is unique to your situation; others reading this will not need to do this)

- Add `ref: 2.13` under "buildorder" in the YAML so it knows which branch to pull from.

- If you don't want to build the module on F28, change build and runtime requires from

platform: [ ]

to

platform: [-f28]

(You could also use `platform: [f29]`, but this wouldn't automatically pick up F30 when F29 branches).

* Push this branch to dist-git and run `fedpkg module-build`

* Submit the module to Bodhi for F28 if desired. F29/Rawhide will appear automatically in the modular repos at the next Rawhide compose.

* Repeat for the 2.27 branch

Optional (recommended) step: submit a PR to https://pagure.io/releng/fedora-module-defaults to have one of the streams made "default" so that `dnf install unison` will Just Work without having to know about modules. Other streams can be installed with `dnf install @unison:2.13