On Wed, Apr 4, 2018 at 12:59 PM Reindl Harald <h.rei...@thelounge.net>
wrote:

>
>
> Am 04.04.2018 um 17:36 schrieb Stephen Gallagher:
> > Hopefully this will become easier once we get the PHP maintainers to
> > move over to building Fedora Modules. Then we can decouple the PHP
> > updates from the Fedora release and we can tie the NextCloud streams to
> > a known-working PHP stream
>
> thanks god i biuld the PHP stack for a decade on my own - go away with
> the "modules and atomic only attitude" - or at least don't compromise
> parts of Fedora which i still prefer as distribution packages - that
> won't change and before it changes 40 machines are moved to a different
> distribution
>
> OK,  I'm going to try to translate this, because it wasn't altogether
coherent.

I *suspect* you're confusing the version of Modularity that we're shipping
in Fedora 28 Beta with the one we prototyped and abandoned during the
Fedora 26 and 27 cycles.

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.

So, to recap, packaging as modules means you can avoid people complaining
about
1) "The version in Fedora is too old! I want the latest one!"
2) "I upgraded to the new Fedora release and my application stopped
working!"
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to