Announcement

Collapse
No announcement yet.

MariaDB 10.4 + PHP 7.4 Slated For Fedora 32

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    You also don't need containers to use a different version of PHP to the default install. Just compile it up from a tarball (or even from a modified srpm) and use a different DESTDIR during the make install stage.

    I have personally never quite understood Linux magazines for this reason; they do a review of a Linux distro and it is basically like every other single review just with slightly different (and pointless) version numbers. The only place where it matters is in massive (effectively monolithic) software where it is almost impossible to backport such as large desktop environments or even Xorg. For example it is easier to update the Linux kernel itself rather than update Gnome 3.

    Comment


    • #12
      Originally posted by kpedersen View Post
      You also don't need containers to use a different version of PHP to the default install. Just compile it up from a tarball (or even from a modified srpm) and use a different DESTDIR during the make install stage.
      Who compiles PHP from tarball for (or on) production servers?
      I've seen VMs, chroot, manual installation of package with an install option to install it in a different folder... but no compile.

      I have personally never quite understood Linux magazines for this reason; they do a review of a Linux distro and it is basically like every other single review just with slightly different (and pointless) version numbers.
      Decent reviews will look at the customizations done in the distro. In serious distros (Mint, OpenSUSE, Manjaro, Solus, Mandriva and others) there are distro-spoecific patches, GUI tools and customizations that are not available (or would not make sense) upstream.

      The "copy-paste" sensation is mostly prevalent in Ubuntu and derivatives or in distros where they strive to not differ much from upstream (like Arch).

      Comment


      • #13
        Originally posted by DebianLinuxero View Post
        -Fedora 32 : the distro without 32 bit support.
        Fedora is actually in a really good position to drop 32bit support. I wouldn't be surprised if it does drop multilib.

        It's heavily pushed containers, including Flatpak, to the point that most things 32bit is already taken care off. Steam? The Flatpak runs 32bit games on a 64bit-only host and it works remarkably well. Additionally, the Flatpak runtimes will still be supported, so it's not as if they're going to be left on old versions.

        Anything else? containers.
        Last edited by Britoid; 13 September 2019, 10:45 AM.

        Comment


        • #14
          Originally posted by Britoid View Post

          Fedora is actually in a really good position to drop 32bit support. I wouldn't be surprised if it does drop multilib.
          You wouldn't be surprised, but at least I hope you'd be worried. Dropping multilib is still a bad idea.

          Comment


          • #15
            And in breaking news...

            New release of popular distro ships with most recent stable versions of some packages.

            Comment


            • #16
              Originally posted by starshipeleven View Post
              Who compiles PHP from tarball for (or on) production servers?
              They probably don't compile PHP in the container; they probably do it at prep / provision time.
              PHP has a lot of compile flags; the defaults cannot appease everyone and modules only go so far; I imagine this is a good reason to compile your own (and of course to maintain a really crusty PHP4 era system).

              Comment


              • #17
                Originally posted by msotirov
                I thought we're past the age where anyone runs their web services on the actual host OS. Who cares what version of PHP they ship in the age of containers.
                Coincidentally i was looking to update an old but working Centos webserver setup soon. I might wait til Centos 8 before doing it though Is there nay good write up comparing the containered approach?

                I was thinking using the UBI for php and for mariadb. Is that a good approach?

                Comment


                • #18
                  Originally posted by kpedersen View Post

                  They probably don't compile PHP in the container; they probably do it at prep / provision time.
                  PHP has a lot of compile flags; the defaults cannot appease everyone and modules only go so far; I imagine this is a good reason to compile your own (and of course to maintain a really crusty PHP4 era system).
                  I guess it's possible, It's just that most of the time I see PHP it's for some (imho craptastic and overkill) framework like Joomla or something basic like that and it does not need recompiling.

                  So I was curious.

                  Comment


                  • #19
                    Originally posted by kpedersen View Post
                    You also don't need containers to use a different version of PHP to the default install.
                    I use https://rpms.remirepo.net/ to install an alternate newer PHP release. In fact, with PHP-FPM and the versioned install trees the Remi packages use, you can actually install muliple PHP releases at the same time (you just have to proxy to the appropriate version in each virtual host).

                    This is how control panels like cPanel do multi-version PHP support and is very handy for per-site PHP version migration where one Web server is hosting multiple PHP-using sites.

                    As for MariaDB, the repos at https://mariadb.com/kb/en/library/ma...tup-and-usage/ on tne official MariaDB site are pretty good and well worth using instead of your distro's shipped MariaDB.

                    Note that both Remi's PHP and MariaDB's official repos have split minor releases into separate repos, which can make minor updates rather awkward. It can mean actually having to delete the old packages (including the repo package/config) and install the new repo and packages from scratch. I think this is done because the "minor" X.Y versions are actually quite long-lived and often have a lot of feature changes, so they're more akin to a more traditional "major" version.

                    Comment

                    Working...
                    X