Announcement

Collapse
No announcement yet.

Fedora Updates Its Packaging Policy To The Ire Of Some Developers

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

  • Fedora Updates Its Packaging Policy To The Ire Of Some Developers

    Phoronix: Fedora Updates Its Packaging Policy To The Ire Of Some Developers

    Fedora has updated its packaging policy to allow more software to be bundled in the Fedora repository, but not everyone is happy with this change...

    http://www.phoronix.com/scan.php?pag...-Policy-Update

  • #2
    It is a mixed bag, but in the long run I'd like to see a Linux disto take an approach similar to what Apple does on the Mac. That is come with app bundles that contain app specific resources. The reality is there is sometimes good reason for an app to deviate from the norm, having a formal way for them to handle non standard libraries is better for everybody.

    The only real question is this: is Fedora proposed approach here robust enough? That is will it cause problems for compliant software.

    Comment


    • #3
      I don't like this but even Gentoo has to compromise in this area sometimes. We don't have such strict rules. It can really screw things up in ways you don't expect though. I pushed hard for FreeSWITCH to stop bundling some of its libraries and eventually managed to get that ball rolling. One particularly fun issue was that DTMF matching on a Rayo-controlled call would always fail because it was using the system version of libpcre over the version it had been bundled with as a result of a long chain of shared libraries that included SELinux. This only appeared on certain systems like recent versions of Fedora, hence why they didn't spot it themselves.

      Comment


      • #4
        Originally posted by wizard69 View Post
        It is a mixed bag, but in the long run I'd like to see a Linux disto take an approach similar to what Apple does on the Mac. That is come with app bundles that contain app specific resources. The reality is there is sometimes good reason for an app to deviate from the norm, having a formal way for them to handle non standard libraries is better for everybody.

        The only real question is this: is Fedora proposed approach here robust enough? That is will it cause problems for compliant software.
        Yes, for god's sake just let the app developer who does all the testing see what libraries are the best for hist software.

        Comment


        • #5
          Originally posted by doom_Oo7 View Post

          Yes, for god's sake just let the app developer who does all the testing see what libraries are the best for hist software.
          Right, and this way you end up with a buggy and unsecure openssl (for example) in half your applications, because the app developer cant' be bothered to update something that "just works"...

          Comment


          • #6
            Originally posted by Serafean View Post

            Right, and this way you end up with a buggy and unsecure openssl (for example) in half your applications, because the app developer cant' be bothered to update something that "just works"...

            Agree. If using system libraries was the normality then much more peoples would have tested the software against different libraries and bugs would be ironed out quicker.
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              Originally posted by Serafean View Post

              Right, and this way you end up with a buggy and unsecure openssl (for example) in half your applications, because the app developer cant' be bothered to update something that "just works"...
              Packaging a library that is already supplied look a lot like a violation of the DRY principle to me.
              But I guess this can be debated to death and beyond. Because developers tend to think of the OS as a baseline, therefore they are entitled (and in some cases forced) to package newer versions of default libraries. On the other hand, if you want software to use the supplied libraries, you'll find yourself unable to update them when the API changes (yes, I know Linux can handle this). So there are arguments going both ways and since no camp is clearly bigger than the other (has this ever been measured?), there's really no way to settle this, other than setting a course and hoping other will follow.

              Comment


              • #8
                so thats basically "hello" to forking instead of fixing...?

                Comment


                • #9
                  It is a complex issue imho. As written above, allowing apps to bundle what they want seems like a maintenance/security nightmare. On the other side, it has happened to me often enough on fedora, that a more recent lib version I wanted to use was not available, due to being blocked by other apps requiring older versions.

                  Comment


                  • #10
                    IMHO, it's a question of a changed balance between application developers and distros. Formerly, it was crucial for apps to be included in the distro to reach the users. This meant that distros could add some pressure on applications to get the overall system stable.

                    Right or wrong, nowadays the same devs feels that whether their app is included in a distro or not isn't an issue. Users should "just" use whatever tool the community uses (pip, builder, ...) and install/update applications using that.

                    While I think this view misses important parts of the user perspective, this seems to be how it works these days. The Fedora move is a try to stay relevant by including some pieces of sw which many users want, sacrificing some stability and security in this new world. We'll see how it works...

                    Comment

                    Working...
                    X