On Thu, May 31, 2018 at 1:33 PM Stephen Gallagher <sgallagh(a)redhat.com>
On Thu, May 31, 2018 at 9:49 AM Richard W.M. Jones
> 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
> > 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 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
- 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
Accidentally hit send.
This and other streams can be installed with `dnf install @unison:2.13` or
`dnf module install unison:2.13`
And I would have inlined this above, but you will also want to add a
Profile: section to the YAML with at least a profile named 'default' so DNF
will know what packages to install if you use the module syntax that I
showed for "other streams".
an explanation of profiles (and the rest of that file for details on the
format in general, though most of what you'll need will have been added by