Page 1 of 4 123 ... LastLast
Results 1 to 10 of 31

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,611

    Default 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. #2
    Join Date
    Mar 2008
    Posts
    579

    Default

    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 at 11:24 AM.

  3. #3
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    980

    Default

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

  4. #4
    Join Date
    Nov 2011
    Posts
    304

    Default

    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.

    Quote 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.

  5. #5
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote 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.

  6. #6
    Join Date
    Feb 2012
    Posts
    111

    Default

    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

  7. #7
    Join Date
    Oct 2007
    Posts
    1,322

    Default

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

    unintended installs
    I think you meant unattended installs...

  8. #8
    Join Date
    Dec 2010
    Posts
    9

    Default

    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.

  9. #9
    Join Date
    Nov 2010
    Posts
    450

    Default

    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.

  10. #10
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •