On Thu, May 31, 2018 at 9:49 AM Richard W.M. Jones <rjones(a)redhat.com>
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
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
> 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:
The cliffs notes version:
* Resurrect the 'unison' (unversioned) package
* 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
- 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
platform: [ ]
(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
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