Announcement

Collapse
No announcement yet.

RPM 4.10 Release Supports The Tilde, 7-Zip

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

  • RPM 4.10 Release Supports The Tilde, 7-Zip

    Phoronix: RPM 4.10 Release Supports The Tilde, 7-Zip

    Version 4.10 of RPM has been released with many new features...

    http://www.phoronix.com/vr.php?view=MTEwNzU

  • #2
    There are 0 reasons to have both RPM and DEB systems. Just a mess for maintainers with no real advantages for end-users in having one instead of the other. If there were real advantages of one over the other, then just adopt the best one. Instead no, we have to have 2 systems just for the glory of uknown anti-end-user reasons.

    To make it short: We all know DEB is better than RPM, the problem is that Red Hat, the biggest commercial Linux solution, for historical reasons uses RPM. And for this reason, we still have RPM. I call this an issue.

    Let's not even mention all the other packaging systems. Each of them says "Hey, mine is better than yours". Sure sure, yours is of course longer than mine. If everyone think like that, today there would be 0 international standards. And this is why I just hate that each "major" distro has its own way of doing its packaging system. Sure, once again, yours is of course longer than mine. They all say the same thing.
    Last edited by bulletxt; 05-26-2012, 10:24 AM.

    Comment


    • #3
      This is just RH acceding to the popularity and technical superiority of apt/dpkg

      Comment


      • #4
        To make it short: We all know DEB is better than RPM, the problem is that Red Hat, the biggest commercial Linux solution, for historical reasons uses RPM. And for this reason, we still have RPM. I call this an issue.
        Complex of superiority symdrom from that post. Deb packaging success is mainly due to its policies rather than technical RPM still edge DPKG.
        Next time, do a proper research instead of relying to a "holly debian style zealotry" because it is "oh my god, red hat is the devil" style.

        Originally posted by DeepDayze View Post
        This is just RH acceding to the popularity and technical superiority of apt/dpkg
        False. That argument intention is only for trolling purpose with the use of apt, nothing more.

        Comment


        • #5
          Originally posted by DeepDayze View Post
          This is just RH acceding to the popularity and technical superiority of apt/dpkg
          Bullshit.

          What makes deb more popular is the huge amount of work that Debian puts into it. It's brute force that makes it work.

          RPM has a number of technical advantages. One of the big ones is that it's designed for unintended installs and updates were as Debs depend on debconf. This means that the _RIGHT_ way to perform automated updates and installs for Debian is to do it all manually a head of time and then setup pre-seed files with the answers you need. This dependence on debconf makes it more of a hassle to deal with then rpm. Most of the time people resort to hacks like reconfiguring cron-apt to install packages rather then just downloading updates for you to install later. I could go on with other examples, but there is no point to it because either you understand at this point or you are not going to care about technical arguments and just blather on about nonsense.

          HOWEVER...

          In reality Slackware is right. There is no need to have anything much more complex then Slackware's tarball format they use. It's just a tar.gz file with a description file containing metadata about the package. Add the ability to sign files or signed package lists of package checksums then you are set.

          Linux distributions depend way too much on package management systems to paper over lack of discipline in userspace APIs. People regularly change APIs for applications which causes breakage during major updates and between releases. There isn't really a good reason why a package from 3 years ago shouldn't work today for end user applications. Distributions just depend on putting significant amount of human resources into solving API/ABI breakage issues and this means that resources are tied up on duplicate efforts instead of bug fixes and improvements.

          In reality distributions should NOT be packaging software, except for 'core linux' stuff and software developed by the distributions. Software packages should be built by developers and those packages should be gathered up by distributions for their package repositories. Gnome packages should be built by Gnome. KDE packages should be built by KDE. XFCE should be built by XFCE.. Games built by game makers. Chrome built by Google, etc etc. Then distributions just pull in the packages they want for their repos.

          All in all for end users this means that IF the software they want is packaged by distributions then it's great. But if they want to use something that is not built specifically for their current version of their OS then it's a PITA.

          Comment


          • #6
            In reality distributions should NOT be packaging software, except for 'core linux' stuff and software developed by the distributions. Software packages should be built by developers and those packages should be gathered up by distributions for their package repositories. Gnome packages should be built by Gnome. KDE packages should be built by KDE. XFCE should be built by XFCE.. Games built by game makers. Chrome built by Google, etc etc. Then distributions just pull in the packages they want for their repos.
            And you pretty much kill the concept of "distribution" in there ... because you're omitting A LOT of variables

            Comment


            • #7
              Red Hat is like an oh-so stubborn country that won't adopt the metric system.

              unintended installs
              I think you meant unattended installs...

              Comment


              • #8
                I'd take rpm spec files over the mess that is the debian build system any day. The macros are very useful and standardized albeit there are distribution specific options, such as for build systems. The syntax is not bad either. All in all, rpm follows a fairly principle of least surprise approach and lets you build software properly for a distribution in a manner that doesn't involving throwing away more time than you should have to.

                So here's why rpm should win: Quicker, cleaner, and leaps and bounds more straight forward (especially in organization). I do hate needing to use cpio to extract an rpm though.

                Comment


                • #9
                  the only way to solve this is to unify a new standard that the big distros can agree to get this mess cleaned.

                  In the end if they want to call it "DPM" or "DEM" or whatever is ok with me.

                  Comment


                  • #10
                    Originally posted by bulletxt View Post
                    To make it short: We all know DEB is better than RPM, the problem is that Red Hat, the biggest commercial Linux solution, for historical reasons uses RPM. And for this reason, we still have RPM. I call this an issue.
                    Do you have any reasoning for this, or are you pulling this out of your ass?
                    You sound like a fanboy.

                    Comment


                    • #11
                      all i know is that one of them must die. i don't care which or if its both and have something replace them.

                      FFS how difficult it is to have canonical redhat and all the other distros to seat down and decide on one way of distributing software on linux.

                      Comment


                      • #12
                        Originally posted by 89c51 View Post
                        all i know is that one of them must die. i don't care which or if its both and have something replace them.
                        What do you think that will solve? It's not like the new format would mean that packages for different distributions would work with the other. Even if it would reduce a bit of duplication I don't think that it would change anything much as both projects seem to have only a few active contributors.

                        Comment


                        • #13
                          Originally posted by Teho View Post
                          What do you think that will solve? It's not like the new format would mean that packages for different distributions would work with the other. Even if it would reduce a bit of duplication I don't think that it would change anything much as both projects seem to have only a few active contributors.
                          First and foremost it will eliminate any confusion for the new users. Secondly it will make the life of devs easier. Proprietary software will be easier to install. And probably there are other advantages.

                          As for the distribution i would like a centralized "place" where i can get my software. A unified linux appstore of some sort that even if i end up to the project website i would have to go through the appstore to get what i want (ie. click a link and open the appstore). Options to built from source or use nightly stuff or dev packages are something that i would like to see if technically possible.

                          The user experience as it is now is horrible.

                          Comment


                          • #14
                            Originally posted by madjr View Post
                            In the end if they want to call it "DPM" or "DEM" or whatever is ok with me.
                            How about DERP.
                            Incidentally quite suitable, also for some people and comments here...

                            Comment


                            • #15
                              Originally posted by nevion View Post
                              I'd take rpm spec files over the mess that is the debian build system any day. The macros are very useful and standardized albeit there are distribution specific options, such as for build systems. The syntax is not bad either. All in all, rpm follows a fairly principle of least surprise approach and lets you build software properly for a distribution in a manner that doesn't involving throwing away more time than you should have to.

                              So here's why rpm should win: Quicker, cleaner, and leaps and bounds more straight forward (especially in organization). I do hate needing to use cpio to extract an rpm though.
                              Arch's PKGBUILD is quite similar to an RPM spec file as well and Arch's build system is straightforward. Debian has a control file that spells out what is required of a package and I concur it is a bit of a mess though but Debian is working on improving APT all the time

                              Comment

                              Working...
                              X