On Thu, May 31, 2018 at 9:49 AM Richard W.M. Jones <rjo...@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
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OVOXWLLCLTFV7OYOQY6NY5EJQUVZWZ5J/
