The short version is that Modules *are* distribution packages. They're just distribution packages that allow you to pick which major release stream you want to stay on. We also have a distribution-level defaults setup that allows you to pick one stream from the module and call that the "default" for a particular Fedora release. Once that stream is so marked, it just shows up automatically in DNF identically to the way that traditional distribution RPMs do today. So let's say that in Fedora 28 you make PHP into a module with the stream "7.2". We mark that as the default. People can then `dnf install php` exactly as they always could; the only thing they might see different would be the %{release} tag of the RPM. Now, let's assume that PHP upstream decided to release 8.0 next month. Fedora 29 would probably use that as its default module and would package the same way as the above. *However*, you now also have the opportunity to mark the module as being available for both F28 and F29 and the Module Build Service would produce it for both. And now users of Fedora 28 can opt in to 8.0 before F29 is released if they want to. And the reverse is true as well: when upgrading to Fedora 29, users can opt to keep their version of PHP on 7.2 to continue supporting their application.

On Wed, Apr 4, 2018 at 2:36 PM Przemek Klosowski < przemek.klosowski(a)nist.gov&gt; wrote: > On 04/04/2018 01:59 PM, Stephen Gallagher wrote: > > The short version is that Modules *are* distribution packages. They're > > just distribution packages that allow you to pick which major release > > stream you want to stay on. We also have a distribution-level defaults > > setup that allows you to pick one stream from the module and call that > > the "default" for a particular Fedora release. Once that stream is so > > marked, it just shows up automatically in DNF identically to the way > > that traditional distribution RPMs do today. So let's say that in > > Fedora 28 you make PHP into a module with the stream "7.2". We mark > > that as the default. People can then `dnf install php` exactly as they > > always could; the only thing they might see different would be the > > %{release} tag of the RPM. > > > > Now, let's assume that PHP upstream decided to release 8.0 next month. > > Fedora 29 would probably use that as its default module and would > > package the same way as the above. *However*, you now also have the > > opportunity to mark the module as being available for both F28 and F29 > > and the Module Build Service would produce it for both. And now users > > of Fedora 28 can opt in to 8.0 before F29 is released if they want to. > > And the reverse is true as well: when upgrading to Fedora 29, users > > can opt to keep their version of PHP on 7.2 to continue supporting > > their application. > > > This is cool---so what command do you use to choose PHP 8.0 in F28? and > how do you choose to stay on 7.2 in F29? On F28 `dnf install php:8/server` (Assuming there's a profile called "server" with the packages one would need to use PHP in a server context) On F29, if you have the php:7 module enabled in F28, an upgrade will not switch this on you. If it's a clean install: `dnf install php:7/server` (Note: I don't know if PHP is backwards-compatible between minor versions; If it's not, then it would probably be php:7.2 and php:8.0 instead) _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

On F28 `dnf install php:8/server` (Assuming there's a profile called "server" with the packages one would need to use PHP in a server context) On F29, if you have the php:7 module enabled in F28, an upgrade will not switch this on you. If it's a clean install: `dnf install php:7/server`