Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software Businesses

RPM Package Manager 180

Posted by Hemos from the making-things-easier dept.
Things have changed quite a bit since we last posted about the state of Linux Package Management. Over the few months ago, we saw the Connectiva release, which was a RPM front-end to apt-get [?] . Now, for those of you running RH6.x, there are a new program called Aduva Manager. It's kinda like using apt-get update/apt-get dist-upgrade, but checks dependecies and such for RH6.x based systems. They've got screenshots as well as a FAQ/download site. It's designed more for new users, but it looks like a step in the right direction for RPM.
This discussion has been archived. No new comments can be posted.

RPM Package Manager More

RPM Package Manager

Comments Filter:
  • up2date from rawhide is more or less from apt-get

  • Package Managers (Score:3)

    by GW Hayduke ( 19878 ) on Wednesday December 27, 2000 @10:37AM (#1410305)
    It's been my humble opinion that packaging managers are good for "users" of OS's I just started using debian on my workstations after a co-worker showed me the ease of applying new dependancies. However without getting into a distro jihad here, I still say that for the tried-and-true, the only REAL way to understand and comprehend services on a production box, you really need to compile the source yourself.
    How else are you going to be able to troubleshoot or modify any tweaks/perks/or problems that may occur.
    Or take for example the debian debacle of a couple weeks ago. I did an upgrade then an install of a couple things only to find out that X was going to crap the bed on me... If I had been less lazy (yes I know that goes against EVERY netadmin's fibre) and had compiled the programs myself I could have saved a couple hours of time in the long run.
    But as far as getting *nix out to the masses I applaud RH and Debian for attempting to ease the installation of software for new users.
  • ...a standards comittee!

  • ...regarding why Red Hat use RPM, and not Debs? I thought there was a great consensus that the debs system is superior to the RPM system, and considering that Red Hat need not worry about copyright infringement, why do they continue to use RPMs? Is it because they have a perhaps misguided feeling of pride regarding their package management system?

    I suppose some will argue that it is because RPM is the 'standard', but the fact is that the standard is pretty much whatever Red Hat decrees it to be.

    I just don't understand why Red Hat are continuing to use an arguably outdated system.

    KTB:Lover, Poet, Artiste, Aesthete, Programmer.

  • Hmm, when did slashdot start taking over for freshmeat? I though they were the ones listing new software releases. Perhaps part of a hostile takeover within the andover ranks?

    --

  • I'm so sick of... (Score:3)

    by uradu ( 10768 ) on Wednesday December 27, 2000 @10:41AM (#1410309)
    ...these organic GUIs. Why do we need to have widgets that look like automobile clay models or stuff you'd find if you slit open your guts? What's wrong with good old 3D widgets, which took us like 10 years to get to?
  • "RPM Package Manager"? Is that anything like "scuba apparatus"?
    --
    MailOne [openone.com]
  • I like my rpm based distro, SuSE. I like how they have implemented booting, system changes, etc. I like what options they give at install. I don't like trying to change it ever after it's on there though, because it makes upgrading impossible because the downloaded tar.gz's don't work the same way as they otherwise would have. Maybe in the next six months to a year something will FINALLY be done... Debian is a nice distro, but it's definitely not easy to install...

    "Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
  • This assumes that you can and do *read* the source. I know that for me to type ./configure make make install does not give me any more understanding and control then does typing apt-get install foo. For many of us admin types who can code a little but at nowhere near the level we would have to in order to really use the code it is worthwhile to let the fine folks of the Debian project take care of the details. And BTW I have never ever seen stable randomly break things that did not end up being my fault in the end so if you are running unstable well you should know better.

  • Re:sounds like up2date (Score:1)

    by Anonymous Coward
    up2date doesn't do not even a bit of what this program does. Among other features it's got:

    * kernel upgrade - not an RPM upgrade, but entire compilation - with 2 clicks
    * dependecy problem - no more. Just upgrade or install - without depenedency headache
    * Upgrade entire trees in single click - want to upgrade all your development enviroment? select the branch - and click "upgrade now"
    * Hardware support - newer driver comes out? you couldn't install driver or didn't find it? the Manager will do this for you.
    * 1 place to download your software - no need to look for RPM's - the program is connected to their server and download what you want from there - with support to broken connection and proxies.
    * Built in search engine for RPM's - no need to guess RPM names
    * Completely depend from your Desktop enviroment/Winidow manager - whatever you run KDE/GNOME/Enlightment/twm/fvwm/you-name-it - it doesn't need anything
    * Its totally free and soon the source will be out..

    Now - can you compare those features to any other package management or other solutions available for Linux?
  • Debian is definitely not an easy distro to install, especially for beginners. But, IME the debian system keeps better track of installed components and dependancies, which could possibly make eveyday (un)installing much easier and streamlined for the average newbie.

  • The shifting sands of Linux (Score:3)

    by Kiwi ( 5214 ) on Wednesday December 27, 2000 @10:47AM (#1410315) Homepage Journal
    I am sure a number of people will reply by complaining that this does not work with RedHat 7. The fact that it does not work with RedHat 7 highlights what is both a good thing and a bad thing for Linux:
    • Linux is in a constant state of change.
    A slick program like this takes many man hours to develop. Due to the constant changes done to Linux, developers not only have to do all the effort involved with developing their program, but also have to expend a lot of effort keeping track of every single change to the Linux distributions thrown their way.

    There is a lot of excitement in the Linux community about getting the latest distribution of (Debian/RedHat/SuSE/Slackware/whatever). This excitement oftentimes results in neglect of older, oftentimes more stable releases of Linux systems.

    To RedHat's credit, RedHat still supports releases as far back as RH5.2, in the sense they still releases security upgrades for RH5.2. About a year ago, RedHat silently stopped releasing security upgrades for RH4.2. Since I still run a RH5.2 server (too far away and too mission-critical for me to conveniently upgrade), I dread the day no more security patches are made available for RH5.2.

    I know that the people at Linux Weekly News [lwn.net] have been making somewhat of a stink over the fact that Debian announced that they would not make available security patches for 2.1 bugs immediately after releasing Debian 2.2.

    Anyway, the point being: The "latest and greatest" is not always the best solution.

    - Sam

  • RPM Package Manager, isn't that like ATM Machine, or VIN Number?
  • from non-technical sides how about the price?
  • That's not humorous at all. Please make way with your parody on such sensitive issues.
  • granted and point well taken. I guess I'm attacking the issue from a different angle. more along the line of the other dependancies that are installed during certain apt-gets.
    and generally depending on where you get the source from, there seems to be more documentation (README's, INSTALL, what have you) to help you out with.
    Yes, I wholeheartedly agree with you that the debian developers who forget more on a daily basis than I will ever learn about their own products have a much better understanding of the tweaks/peeks of the OS and therefore will be able to "fix" any problems long before the majority would even figure out that there WAS a problem.
  • You'd be correct if the files handled by the Package Manager were of the type R. However the actual file extension/file type being RPM the correct term would be RPM package manager. Going along your train of thought, deb package manager would also be incorrect.

  • Or ATM machine, or PIN number...


    --
  • This has been bugging me lately and you are near and the first one I saw this morning but Where does this idea that Debian is hard to install come from and really how long do you spend installing a system. Now granted before 2.2 maybe it was kind of hard because you had to go to dselect to do it. But the 2.2 install is cake. I will give a walkthrough. Boot, tell it what keyboard you want to use, partition, set up your swap partition, mount the rest of your partitions, install the kernel, choose modules (drivers) for your hardware, install the base system, set up networking and time, install lilo, reboot, give it a root password and make another user, choose simple and choose the tasks you want to install, pay a little attention to what packages are installed by default note any you would like to get rid of, let it install what it needs to, answer some basic config questions if not sure the defaults are really sensible, apt-get remove anything you don't want (I just hate XDM) apt-get install anything you want (Netscape and Mozilla are both good) Run xf86config (If this is hard for you maybe you really should be running RH)and you are done. Now really what was so hard about that? Could somebody please tell me just what is so hard about installing Debian?
  • Please do not reply to the idiot. Giving him/her/it* attention will only make it worse. Just adjust your threshold.

    * Underline appropriate option. Multiple options may be valid.
  • I am sure a number of people will reply by complaining that this does not work with RedHat 7

    What's ironic is that RedHat's up2date service doesn't support RH 7 either (At least, there is no rhl-7.0 directory under ftp://ftp.redhat.com/pub/up2date [redhat.com] ).

  • Things like this (and helix-update, another neat toy) are vital if we ever expect to get Joe User working with Linux. I bang my head against the screen every time someone says "Package? Why don't you just compile the source?" Say it with me...the majority of the population are not programmers....if you make an OS that is only for programmers, then you will never get market share...

    Besides, anybody who says that compiling their own source automatically makes them better understand their machine must not ever execute those "make install" scripts. If an automated process puts 100 files across 12 directories on your machine, and you tell me you can keep track of them all in your head for 100 software packages, I don't believe you.

  • http://www.userlocal.com/interviews/cantrell121800 /cantrell2.shtml

    in all the way that most distro is adopting what apt-get doing@

    DEBIAN ROCKS

  • My pet peeve is the silly hierarchical package display. You have to figure out exactly where in the hierarchy the developer chose to stick the silly thing. Often a package can logically go in one of several places, and it seems that almost as often, yet a different place was chosen.

    I like xrpm, which gives a flat view of installed packages or rpms in a directory. A long list, but no hiding in odd mislabeled corners.

    Unfortunately, my RH 6.2 has 'aged' too much. I'm seeing too many things that pretty much require me to turn it into RH 7 with prerequisites, so I may as well take the faster route. Then get the updates on, etc.

    RPM is handy for a user, as opposed to a developer. Though I try to understand more of the nuts and bolts of what's happening, my computer is more of a tool than a programming machine.
  • Warning, I am a debian user.

    I don't think that redhat will ever give an automated-updating package manager their full support. It's a pain to get all of the little dependencies for RPM(this depends on that, which depends on those 8 packages, two of which require a new version of pacakge q), which helps them sell cds.

    This is not at troll, but honestly, redhat has to sell cds, and I belive they have held back support for automatically updating package managers because they would rather have their users go out and buy redhat cds.

    Now Eazel and I belive helixcode are gearing up to offer subscription(money)-based automatic system updaters, and I remember hearing something similar from redhat at one point. But I doubt they will ever support one for free. It's a sad fact that often technology advances are held back because a company needs to make money.

    An interesting thing to try would be to make it so you could do bug-fixing upgrades (1.0 to 1.1) but not feature upgrades (1.0 to 2.0). And in order for that upgrade you would have to be running the new version of Redhat. "6.0 lets you upgrade from 1.0 to 1.1, but to get the added functionality of 2.0 you need to buy version 7!".
  • RPM is not at all outdated. .deb packages have a lot of things that are an advantage and a disadvantage at the same time, such as the post-install configuration. We don't want this type of stuff because it makes installation unnecessarily complicated. The only real advantage of debs compared to rpms is apt-get, which has now been implemented for rpms as well. So why switch to anything else?
  • How is .deb better then .rpm?


    Apt-get.

    Cleaner dependencies.

    More package maintainers.

    More packages in the standard tree - fewer compiled by other people who are not part of the distribution.

    More testing.

    Debconf.

    No backward compatibility break between rpm-3 and rpm-4 for debs.

    Nuff said.

  • Those screenshots are terrible. I hope that's a GTK theme or something, because I'd hate to have THAT on my desktop. I'm probably wrong. It's probably all hard-coded ugliness. Or even worse, they went ahead and wrote a whole theming engine for their one app while Qt or GTK already have the ability to make your desktop as ugly as you want.

    I thought web sites were supposed to look more like applications in order to be more usable, not the other way around.

    Who designs this crap?
  • I don't have a problem with "organic" UIs, but I think that this program has a pretty bad UI, organic or not. The parts don't fit together, some are 2D, some 3D, buttons and scrollbars are lit from different directions, and the text is hard to read because you can't find any structures for orientation. So the problem here is IMHO not the organic layout, it's just that the UI is not very well thought out, and done mostly for the effect (and maybe for looking good in computer magazines), not for making the program usable.

  • Or NIC card, Or RPMs...

  • What I took from the original comment, was that the installation of a Debian system is a lot more involved and complex than the installation of (yes)Red Hat or Mandrake or the like. With the importance of the term User-Friendly in the effort to take linux to the common desktop environment and build a user base that consists of more than tech-savvy geeks, Debian lacks a lot to be desired. I can bring copies of windows, the aforementioned RedHat and Mandrake and possibly a few other distros home to my parents house and they can install either without any input from me. The chances of them going to bestbuy, purchasing a Debian CD set, coming home and installing and actually becoming a member of the slowly growing list of *nix users are less than slim.

  • I've talked with Aduva people a while ago, their plans are to add support for 7 in a while.

    As for "silently" dropping 4.2, it's not really true. We have always supported the end-of-line releases for the last 2 major versions, meaning 4.2 was dropped when 7 was released, 5.2 will (unless our policy changes) be dropped when 8 will be released. I'm quite sure this information is publically available somewhere.
  • Anyone check out the Licenses attatched to it? There are a lot. Also mentioned in the licenses:

    ADUVA RESOLVE LIBRARY BETA TEST LICENSE AGREEMENT
    Section 1.
    "a limited, non-exclusive license and right to non-commercial use of one copy of the Program on your desktop computer or on a portable computer, all for the purpose of testing the Program."

    This leads me to believe this will not always be free. You could end up paying for this "service" (the use of their database). Doesn't that violate some of the previous Licenses? After glancing at this, I doubt I will use this. Sounds to sketchy to me.

  • You'd be correct if the files handled by the Package Manager were of the type R. However the actual file extension/file type being RPM the correct term would be RPM package manager. Going along your train of thought, deb package manager would also be incorrect.

    Um... Yeah. Redhat package manager package manager? "deb" isn't an acronym, "rpm" is.

  • AC who would have guessed? LMAO

  • Linux mandrake autodetected all my hardware. Debian autodetected none of it. It was a bit of a pain to try to figure out which driver my ethernet card needed, and dusting of the monitor manual for refresh rates. And manual mouse and video card configuration is a pain, except I had tried those before so they ddin't really take long.
    And now I am at it, I had to download a lot of drivers etc. before I could start on the network install. I can't see why it couldn't just put all the essentials on one floppy and then get the rest of the base system over the network.
    Oh, and dselect is a horrible user interface. They really need a good graphical one under X. (I use apt currently)

    But when installed debian is really nice and robust. After all, why else would I use it? :)
  • but it isn't. i really wish redhat would drop their distro and go with debian.

    in fact, i wish all the distros would re-center around debian.

    how much energy has been spent here, supposedly making "rpm as good as debian", when debian is already the standard of excellence?

    imagine redhat's prowess at making Linux easier...applied to debian. really, all these offshoots seem to be a waste of creative energies.

  • The first thing I thought when I looked at the screenshots was "Looks like Lotus Notes 5.0. Ugh." The program sounds cool in concept, but I wish they'd stick to GTK so the program looks like everthing else on my desktop (except Netscape and Emacs.)

  • Re:The shifting sands of Linux (Score:3)

    by Syberghost ( 10557 ) <syberghost.syberghost@com> on Wednesday December 27, 2000 @11:10AM (#1410342)
    They've also been promising an up2date that works through firewalls "in a couple of weeks" since at least October.

    They won't respond to emails inquiring about this, either; not even to say "we don't have a time estimate yet".

    So, I just continue to report to my Fortune 100 employer that RedHat doesn't have an auto-update solution yet, and doesn't respond to email.

    -
  • this is still a step in the WRONG direction. It's the same problem that mandrake has.. it's pretty, it's GUI, but it's not capeable of being used for automation.. there MUST be a backend library, like apt, to do the real work.. if I can't use it with a CLI, in a shellscript, I can't use it for my network automation. these GUI's are great for users, useless for companies with large network installs of boxes... I don't want to go back to rsync'ing boxes. looks like I get to stay with debian for now. (conectiva's apt port is the right way of doing it.. they are on my list of good distro's now)
  • i guess "rpm" now means "redundant package manager".
    --
  • come on,he is a graduate of computer science don't demand too much

  • Licensing (Score:5)

    by egon ( 29680 ) on Wednesday December 27, 2000 @11:20AM (#1410346) Homepage
    Did anybody see the licensing on this? Read on...

    12. Access to the ADUVA Server

    Aduva provides at present free of charge access to the ADUVA Server and to the
    ADUVA KNOWLEDGE BASE. Aduva may charge in the future for access to the ADUVA
    Server and/or the ADUVA KNOWLEDGE BASE. The information and/or any other data
    received from the ADUVA Server is the sole property of Aduva and is protected
    by copyright and other rights.

    I wonder if they have a privacy policy...
    --
    Give a man a match, you keep him warm for an evening.
  • While learning the internals of the environment, by doing things the hard way, has always been the best way in my book, but when it comes to system administration, having Debian's package manager is extremely helpful. 1st, if you run more than one box (which I run 12 servers at work, 1 for my LUG, 5 for a local freenet, plus my "personal" server on my home DSL line) managing software becomes a nightmare. I'm not really crazy about Sun's package manangement, but without it (and thank god for patch clusters) it would be next to impossible to manage the 12 systems at work. The rest of the systems all run Debian, and it really does work better than Redhat's releases. Do you know what I hate? Reading Redhat's ERRATA page on a constant basis to see if a package has been updated. With Debian, I just "apt-get update; apt-get upgrade" to grab the latest updates.

    It's always been my opinion that Slackware is the best (and hardest) distribution of Linux to start out with, because you learn HOW to do things the hard way. This is an important step in the learning process. The next step is to learn how to do it BETTER. I do not recommend Debian to new users unless they are coming over from Solaris or other commercial Unix. Its not for novices trying to learn with, its for Linux users who have a job to do.
  • Dont care how much people tell me, no dist is perfect, Debian is far from perfect, like Redhat, Slackware, etc are also.

    Use what you want, but dont try to convince someone else that their dist is so inferior to yours. The major advantage of Linux is choice. No one vendor, no one controlling group.

  • bero (Score:1)

    by gimpboy ( 34912 )
    whats your opinon of aduva?

    use LaTeX? want an online reference manager that

  • Re:I'm so sick of... (Score:3)

    by HeUnique ( 187 ) <hetz-homeNO@SPAMcobol2java.com> on Wednesday December 27, 2000 @11:21AM (#1410350) Homepage
    It will be skinnable in newer versions, so you will have this GUI, as well as the standard GUI that you're used too.
  • There is no intent to fleece the private users. In fact, it is probably not profitable. However, the way the program works, if for some reason the user grows tired of the Aduva Mangler - all that needs to be NOT done is run the program. C'est touts. :-)
  • dmorin, you have said what I have been yelling at my screen while reading earlier posts, but in a much nicer way!

    Go the binary, get the .deb/.rpm, and you have a (mostly stable, especially with potato) working program straight away. if theres a problem, talk to the author or go get the source... 99.9% of the time there is no problem.

    running 'make install' won't help you understand anything about the source, you must spend time to read and track the source. considering i have over 800 packages installed, the compile-all approach would only work will on a 486 with a 100mb hd.
  • ADUVA is not a free software boycott it

    apt-get is superior

  • Boy, I'll second that. It looks like it was put out by Netscape.

    --
  • not yet. we may be adding support for beowulf, depending on demand. Let's see demand, eh? Easier to canvass resources if the community raves for it, no? ;-). M
  • "the only REAL way to understand and comprehend services on a production box, you really need to compile the source yourself."

    i agree; that's how i learned *nix system administration. but it gets old pretty quick, when you have to download, configure, compile, install and tweak a dozen or so programs just to have a system that does what you need it to.

    once you have reached the level where you understand what is going on, you will start looking for a way to remove that drudgery. for me, debian was the way. most packages install and work out of the box, so most system admin tasks involve customizing your setup, e.g. to make apache do a bunch of virtual hosts.

    as for your problem with X, what do you expect when you run the unstable distribution? if you want a rock-solid system, use potato.

    oh, and X takes several hours to compile. so you wouldn't have saved that much time anyways.

    --
  • You've hit the nail on the head there. The great claim of open source development is that the best solution survives while the weaker ones go to the wall.

    This may be true when your user base is elite CS Grads at Berkerly, but you have to wonder if these days Linuxs user base is not as tech-savvy as it once was, back in the good old days of v1.119

    Honestly, this might sound a bit dumb, but I don't see what is so difficult about using gzip, tar and gmake. I mean, if you cannot figure out a few simple commands, maybe you shouldn't be using Linux in the first place !!! Its not for joe average, its for people who like to get under the hood and tinker around.

  • ".deb packages have a lot of things that are an advantage and a disadvantage at the same time, such as the post-install configuration. We don't want this type of stuff..."

    Erm, actually RPM has had optional pre- and post- install/uninstall script capabilities for a while now. At the moment they're mainly used for running ldconfig, though I have seen them used for generating post-install SSH keys, and for setting an SQLd password interactively from the shell prompt.

    I wonder how well GnoRPM would cope with that, though...
  • That's probably because RH7 has it's own update manager that looks like it's derived from the Helix Gnome updater
    --
  • Yes you install it and then you are done then you need to maintain it. Now lets see you get the all the new updates for Mandrake with two commands. Keep in mind you spend ~1 hour installing a system and after you have done it the first few times it gets really easy then you spend the lifetime of the hardware maintaining it and for that it does not get better the Debian.

  • What all Linux Package Managers Lack... (Score:5)

    by uslinux.net ( 152591 ) on Wednesday December 27, 2000 @11:36AM (#1410362) Homepage
    Unfortunately, all the Linux package managers (apt/dpkg, rpm, etc) lack one vital feature that all the big guys (IBM, Sun, HP) have included for years - the ability to install, but not commit a package.

    One of the things "enterprise" Unices have is the ability to upgrade a package, while the system backs up your old package. If the package upgrade breaks something, it's simple to roll back to the prior state. If everything goes OK, it can be run through it's paces for a while, and then eventually "committed", whereby the old information is deleted.

    Until some flavor of Linux adds this to their package management, Linux WILL NEVER be able to take over the corporate world (yeah, there's a lot of other things it needs to, like 32-bit UIDs and a journaling filesystem, but at least they're on their way).
  • Received the following:

    Date: Wed, 27 Dec 2000 22:31:05 +0200
    From: Ury Segal
    To: egon@tuininga.org
    Subject: Aduva Manager Privecy issue

    [ The following text is in the "windows-1255" character set. ]
    [ Your display is set for the "ISO-8859-1" character set. ]
    [ Some characters may be displayed incorrectly. ]

    Hi!

    I am Ury Segal from Aduva.

    I just wanted to say, in advance to the answers to your question you'll
    probably get tomorrow ( It's 22:27 here ), that your privacy is kept, and
    Aduva Manager does not send the inventory of your computer to our
    servers. All we have is your IP ( and what you asked to download -
    but that's just any FTP site can do. )

    We are making the sources ready for GPL, and then you'll be able
    to check my claim, but till then - you can either sniff the packets and
    see for yourself, or just believe me :-)

    (The stream is SSLed, but it's sniffable if you are
    on one end )

    --
    Ury Segal
    Aduva INC

    Phone: +972-3-7534300
    Fax: +972-3-7534343

    --
    Give a man a match, you keep him warm for an evening.

  • Integration (Score:3)

    by redhog ( 15207 ) on Wednesday December 27, 2000 @11:40AM (#1410364) Homepage
    This program is just one of many coming out lately that does the same error as Microsoft: Merging functionality and user interface. A package tool should consist of either one (or both) of a) a library b) a command line tool. Merging UI and functionality makes it very hard to change the UI (bringing it to a web-based administration, automation, etc) in the future, if needed.

    Unfourtunately, this have been done a lot lately, mainly by KDE developers (No offense, you make a really good GUI, and some really nice functionalities, but could you please separate the two?):

    * KMail have functionality to download mails and filter mails to different mailboxes (It should have used fetchmail and procmail for that, and provided only a graphical configuration tool for those two backends).

    * QT contains both basic datastructures (Linked lists, hash-tables, etc) and GUI widgets (Buttons, listboxes, etc). In GNOME, those two parts are separated in Gtk+ (GUI widgets) and glib (basic datastructures).

    * KDE contains a virtual filesystem that enables the user to transparently use files on remote sites using any KDE application. This functionality should have been in the operating system filesystem layer (There are several projects to achive this (portable): Podfuk, Alex, etc) VirtualFS), since as it is now, only KDE applications benefit. Here I might add that GNOME are unfourtunately heading for the same, developing the gnome-vfs (which stems from the Midnight Commander VFS).
  • This 'Aduva system' stinks of a pay-for-play service of some kind....

    What is the Aduva business-model? What are they planning on doing to feed themselves? Does anyone know?


  • There seems to be some confusions as to what a "package manager" really is. This isn't an 'RPM front-end to apt-get" as Hemos put it. This is a port of apt to support RPM's as a package format. Debian packaging is done through 'deb' packages, which are almost identical to RPM's in form and functionality. Both have evolved to be very good package building, deployment, and retraction tools for software.

    What this, Helix-Update, Eazel Services, apt, and up2date really do is function as package distribution channels. They resolve dependencies, check package location/availability against host-side maintained repositories and download the appropriate packages, once all the dependencies are figured out and resolved. They do not install the packages -- the package manager (RPM, dpkg) does this part. (Well, technically they can, but this would be through either re-writing, or linking to the library form of the package manager.)

    While noone can argue that Debian had this capability first, and probably (currently) does it best due to having time to mature, it's natural that this capability will come to other distros and package formats precisely because it works so well.

    Cheers,
    Ken Crandall

  • Skinnable? *sigh* (Score:5)

    by TrentC ( 11023 ) on Wednesday December 27, 2000 @11:50AM (#1410376) Homepage
    It will be skinnable in newer versions

    I really hope that by "skinnable" you mean that it will use the widget set that your window manager & desktop environment provides, or at the very least provide that as an option.

    That last thing in the world we need are 500 "desktop-ready" applications, each with their own skin format. I already use four different applications that have separate theme formats: XMMS [xmms.org], Nautilus [eazel.com], Mozilla [mozilla.org] and gkrellm [gkrellm.net]. Combined with GTK and Sawmill, that's 6 different theme formats I have to keep track of. (Well, that's kind of a lie; I have Mozilla installed so I can use Galeon [sourceforge.net]...)

    I don't need a themeable package manager, ICQ client, mailreader, image editor, web server, and SETI@Home client. Desktop environments provide those widget sets for a reason...

    Jay (=
  • The program got a built-in search engine, and from GUI aspect, I think a collapse tree is very confusing. The tree is "folded", so you can either "open" the tree or use the search engine..

  • Hey, I got Debian 2.2r1 to install on my 68040 based Mac Centris 660AV, so I'm not saying it's impossible. I've just never had it EVER go as it was 'supposed to'... I've had problems with installing the X Server (in the 2.0 release that I was playing with, the console would cease to respond when working with the X servers and i'd have to manually kill-9 it and try again), I've had problems with dselect, with applications seg faulting on good hardware, and with certain pieces of hardware that worked back in Slackware on the 2.0.0 kernel not work in Debian 2.2r2. Maybe this is being picky, but lots of stuff just gets on my nerves.

    Yes, RedHat, SuSE, Mandrake, etc are easy to install, very easy, like i can put the disk in, boot, select the shiny red button for 'install' (figuratively speaking) and it'll set all the defaults and select all the basic, normal packages. I don't have to do much. Sometimes, like with that Mac, I don't mind a challenge, but when it's just giving me a headache because I want to be able to play sounds or talk to my NIC, it's quite annoying.

    Just my two cents worth...

    "Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
  • >>>if you cannot figure out a few simple commands, maybe you shouldn't be using
    >>>Linux in the first place !!! Its not for joe average, its for people who like to get under the hood and tinker around.

    I disagree... It may have been that way before, but more and more windows users are moving to linux, probably just because of the hype so they are curious. But the easier it is for any user to install and maintain packages, the more users will stay with linux. Sure sometimes its a good idea to compile the sources, but if there's already a package out there, it's just a waste of time. Ideally, no user should ever have to compile the sources- just have it there in case they want it. The thing that is keeping that from happening is the lack of a standard packaging system. RPM works fine, but I really like the apt-get feature of debs. But now that apt is being ported to rpm, then I think I'll just stick with rpm. In the meantime, whoever makes package management easier has got my support.

    But on a side note, I think the interface for this piece of software is ugly and is poor UI design. I personally cant wait for RedCarpet [helixcode.com] from Helix [helixcode.com] to be available - that looks like the best bet right now for package management.


    -Brandon

  • Re:Licensing (Score:3)

    by update() ( 217397 ) on Wednesday December 27, 2000 @12:10PM (#1410388) Homepage
    Aduva provides at present free of charge access to the ADUVA Server and to the ADUVA KNOWLEDGE BASE. Aduva may charge in the future for access to the ADUVA Server and/or the ADUVA KNOWLEDGE BASE.

    Is this different from the policies for the Eazel and Helix Code updaters? They're planning to eventually charge for use of their databases as well. (Hint: That's how they might conceivably make money.)

    The real question is whether the Aduva source will be released -- and according to the license page it will be, under the GPL.

  • As I said in another post - the GUI will be skinnable and you will have the option to use the Aduva Manager with a standard GUI.
  • Right. Because Windows has provided "install, but don't commit" functionality for YEARS. Give me a break.
    -bluebomber
  • The strict policy for Red Hat RPMs (and those of any other RPM based distribution I'm familiar with) is not to demand user interaction in %post, %pre and the likes. debs have a very different philosophy there (or at least used to, haven't checked out the latest Debian yet). We generally use %pre and %post to autogenerate stuff, not to prompt users.
  • Because it's more profitable. How's that you ask? RPM is a for-profit company that relies on you buying new releases of their distro for profit while debian, on the other hand, is not.

    If one could apt-get distupgrade a Redhat box ad infinitum you could buy their distro once and upgrade from that point forward. Debian is a non-profit organization and does not worry about cashing in on the next point release. Debian users upgraded from 2.1 to 2.2 by issuing a simple command. Redhat users sometimes have to deal with dependency problems if they want to upgrade a package and you can imagine what could happen with hundreds of packages.

    Redhat benefits when people buy their distro. They might benefit if they could provide an apt-get frontend with a subscription based service. Although I would love to see an apt-get front end thats free to all, I bet the suits at Redhat corp won't let this happen. I could be wrong, but I think the use of a tool like apt-get and especially doing a distupgrade on a Redhat box is about profit and nothing more.
  • That's good for installation, but what about removal? What about dependency checking during removal? ./configure won't help you there. The only way ./configure works in a sensible way is if it is used in conjunction with encap or stow.
  • It is worse then that. Read the following two clauses:

    2.You may install the program yourself, but you must do so in accordance with Aduva's instructions. The Program is licensed, not sold. This license does not confer you title or ownership in the Program. The Program is not subject to any General Public License and is in whole or part the proprietary property of Aduva. You are specifically prohibited from reverse engineering the Program.

    7.Confidentiality. All elements of the Program, the servers it attaches to, the manner of operation thereof, the code thereof and the information relating thereto are considered confidential information and you agree to maintain such information absolutely confidential and not to disclose such information to any third party whatsoever without first obtaining Aduva's prior written consent.

    More (including a nasty termination clause) can be found on http://www.aduva.com/mason/new/licenses.html [aduva.com]

  • nice! (Score:2)

    by Anonymous Coward
    I just downloaded it and tried it on a machine which I did not touch since I installed Redhat 6.2 on it (it sits here as a printer server), and here is what the program did:

    1. compiled and added sound support for my ES1371 (I didn't know that I have sound card onboard, heh)
    2. Upgraded my Netscape to 4.76 - security update (thats nice!)
    3. updated my gtk

    Then I selected the kernel and clicked Upgrade Now - and it downloaded and compiled kernel 2.2.17 quite nicely..

    Overall - I really like the program - I just really hope that they'll replace the BUTT UGLY GUI and add the option to let me resize the window (it looks very small on EXCEED on my NT when I'm running 1600x1280)

    Good work Aduva!

    YoGi
  • > There's actually some evidence that they are using GTK...

    Nop. QT 2 is being used.
  • Most of the content in Conectiva's site is in http://distro.conectiva.com.br [conectiva.com.br], including news, projects, updates, security annoucements and a webcam [conectiva.com.br].
  • For connectiva package management - you'll need THEIR RPM'S! - I wish you all the best luck to go out and find your favourite RPM in their format.
    Not quite, apt-get is works fine with Red Hat as well, and possibly Mandrake. Check the apt-rpm mailing list archives [conectiva.com.br] for success reports.
  • Helixcode gives you a list of download sites. Which are you choosing?
  • You can't do that with third-party .deb packages as well, unless the packager follows the distributor's packaging policies. So, if these packages are built in a sensible way and posted in a apt-enabled repository, there's no reason to believe it wouldn't work.

    For example, building packages depending on obsolete packages, or packages conflicting with the distro's official packages, is a good way to break apt-get in both Debian and Conectiva.

  • Ok, here's the straight link [conectiva.com.br] for apt packages for Red Hat and a success report:

    I just updated ~10 workstations and ~25 production servers from RHL 6.0 and 6.1 to RHL 6.2. It went fine, no troubles [kernels were already upgraded earlier]. Workstations had ~600 packages (1 GB) worth of RPM's, the servers ~300 (400 MB). :-)
  • If they are currently linking to any GPL component, their beta license would not be legit because it would be in conflict with the GPL. But I've not examined their software.

    Given that they say they are going to GPL it, if they are not currently linking to a GPL component, they aren't doing anything wrong.

    Not that I am sure the business model makes much sense. There are too many people willing to give away what they are seeking to sell.

    Thanks

    Bruce

  • Supporting back releases of Debian is probably within the purview of a commercial Debian derivative, not the Debian organization itself. However, Debian supported LIBC 4 long after they needed to. LIBC 5 is still supported. Debian releases aren't like Red Hat 7.0 (or Red Hat 6.0), they are a good deal more tested and when they are finally released, users should upgrade.

    Thanks

    Bruce

  • Why do so few people use src.rpm?

    I love src.rpm packages for simple reasons, they make instalation and removal a cinch, but at the same time they have all the advantages of source.

    I can recompile with opt flags, change install paths, apply custom patchs, and build myself a nice reusable rpm file for later use.

    For all the people who complain about package systems "robbing me of control" try using src.rpm packages more often, there easy to use, flexable, and give you a nice clean souce tarballs that you can tweak to your hearts content.
  • Well, you do have to have the older version of the package lying around, but that's pretty much what this is.

    Well, technically RPM will automatically deinstall any obsoleted packages on an upgrade, and so you'll also need to grab those as well, but this doesn't happen to often. Besides, you can always do:

    rpm -q -a | sort >before

    rpm -UvhF *.rpm

    rpm -q -a | sort >after

    It shouldn't be too hard to put together a wrapper for RPM that does that, and then reinstall all the older packages if you want to back out.

    ---

  • He original question: How is .deb better then .rpm?

    Apt-get.
    Which is an update program, and not a package program. Mandrake has MandrakeUpdate (along with stable and cooker sources), and I'm sure most other rpm based distros have similar tools.

    BUT - this has squat to do with .deb versus .rpm.

    Cleaner dependencies.
    Is that a function of the format or the package maintainers?

    More package maintainers.
    Again, has nothing to do with .deb file format versus .rpm.

    More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
    Again, squat to do with deb versus rpm. And for that matter, Mandrake's Cooker has most of what I want, being an open submission of Mandrake rpms.

    More testing.
    Hunh? I'm not sure what that means, but I don't think you're referring to rpm versus deb as packages.

    Debconf.
    Okay now THATs more like it - can a somewhat less zealot debian user explain debconf? I'm seriously interested in deb versus rpm (Corel's distro for a two month period was as close as I got to debian).

    No backward compatibility break between rpm-3 and rpm-4 for debs.

    Bzzzt. Thank you for playing. It works fine on my system.

    Nuff said.
    Not only did you manage to sidestep the direct question (rpm versus deb as packages, leaving package managers/updaters out of the scope of the discussion), you merely named a whole bunch of utilities that would only be recognizable to debian users, who, presumably, would not need the information.

    Any debian AND rpm user out there care to take a crack at explaining the difference and pros and cons between the package formats?

    --
    Evan

  • RPM == Red Hat Package Manager

    Seriously, the reason Debian doesn't use RPM is because R=="Red Hat" IMHO. That's the vibe I get from some folks who're involved in Debian. "Ick, that's a RH thing," I've heard more than once. :-) You could make a system (now :-) as easy to use, and as coherent, and as logically laid out, package-wise, as Debian and use RPM. Hell, now, you can even use apt-get with this mythical RPM-based system.

  • Next we'll need a skin-format-manager that can simultaneously select different skins in all managed applications. Yuck.

    Helix Code is working on such a program that they call IIIRC a meta theming engine. It currently has support for Gtk, Sawfish and XMMMS but it should be very modular.

  • SuSE for a long time has had the ability to do updates off the web. You run YaST and tell it your installation medium is an FTP server and then tell it you want to update your existing setup. You can go through and install new apps or just update stuff you already have. It's worked pretty well for me and I've had the same system since version 6.1. Things I would like to see added to this are XML package descriptors vis a vis HelixCode, and support for HTTP updates in addition to FTP. YaST2 does all the stuff YaST does but with a friedlier X interface. I also want GNOME and KDE pluggins for YaST2 that will run in their respective trays and keep me up to date on package updates are up on servers.
  • Apt-get.
    Which is an update program, and not a package program. Mandrake has MandrakeUpdate (along with stable and cooker sources), and I'm sure most other rpm based distros have similar tools.

    Ever tried to use those tools ??

    You are right though - this is not strictly a deb vs rpm issue.

    More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
    Again, squat to do with deb versus rpm. And for that matter, Mandrake's Cooker has most of what I want, being an open submission of Mandrake rpms.

    Actually this has a ton to do with reliability. The entire point of having a distribution is that they will ensure that packaging is reliable and consistent. When third party vendors start offering Redhat RPMs, or Mandrake RPMs, or you start using contrib RPMs, package dependencies get less consistent, and the machine is just not as clean.

    I get everything I need at debian.org in woody non-us and non-free, all packaged by debian maintainers.

    Debconf.
    Okay now THATs more like it

    Debconf is a little scripting conf that allows packages to pop up questions in console windows during the package installation that ask you if you would like to clobber your existing configuration files with new ones or not. The default is always do not clobber. Or, a package can pop up a reminder about a configuration issue associated with a package, and either show or do not show the reminder in the future. Lastly, they have help hints if you cannot resolve a dependency that tell you what to do !! These have helped me a few times.

  • Oh, oh, and it should also have an MP3 player, because they can always do it better anyway. And a file manager. And a plug-in architecture, so I can expand it into an entire OS if I so choose.
  • - wonder if they have a privacy policy... They have one, find it here: http://aduva.com/mason/new/privacy.html
    --------------------------------

  • I've use Slackware before with no problems, and I think the whole idea that Slackware is "hard" is largely outdated. Yes, Slackware used to be more difficult to pick up than something like Redhat, but recently Slackware is not any more difficult or more educational than anything else. Really, is './configure && make && make install' that much more difficult than 'rpm -Uvh' or 'apt-get install'? Slackware even has it's own package management system now too.

    Sure, it's supposed to be the most "UNIX-like" distribution, but what is really UNIX nowadays; with Sun's own CEO calling Solaris "Sun's implementation of Linux"?

  • It has been released for some time now - look for up2date 2.1.7

    As for emails, who did you send them to?

  • The up2date service has been changed, and no longer uses that directory - it's now a part of Red Hat Network [redhat.com]. I like the new program better - I never liked the old one, so I didn't use it much. The new version works nicely, and I use it on my private machines.

  • Red Hat (and almost all the other distributions) use RPM because it works well and is a better and more flexible package format than deb. You're probably confusing "rpm being superior to deb" (package format) with "apt is cool" (distribution of packages)

    RPMs, in contrast to .deb, has cryptographically signed packages (and has had so for ages), flexible and reproducible building method (look at a spec file, they really tell you how to build a package), separated patches(I've seen people claim than .deb can do this, but as long as the packages distributed with Debian don't seem to do this I'll believe that as an urban legend). Take a look at a SRPM and a Debian source package - there's really no competition.

  • Just run "up2date -u", and it will update your system from the command line.

    It can be configured with up2date-config, so if you just want to download the packages or mark certain packages to be skipped you can easily do that as well.

  • We already ship tools for automac update (up2date), and has done so for some time.
  • Actually this has a ton to do with reliability. The entire point of having a distribution is that they will ensure that packaging is reliable and consistent. When third party vendors start offering Redhat RPMs, or Mandrake RPMs, or you start using contrib RPMs, package dependencies get less consistent, and the machine is just not as clean. I get everything I need at debian.org in woody non-us and non-free, all packaged by debian maintainers.


    Really? Mmm... Do you also purchase only Microsoft software, avoiding those nasty "other" vendors that prevent you from having a "reliable and consistent" experience? Because you could replace "Debian" with "Microsoft" there and have a sentence that could come from any number of idiot NT admins that I've run into.



    Point well taken, but the environment is completely different. Everything I need under linux is free (as in speech), and can be packaged by a single party. And the single party is not a vendor with a monetary incentive to lock me in, but a collaboration of hundreds of volunteers.

    There is nothing preventing RedHat from packaging everything that is packaged as RPMs for RedHat from third party vendors. The packaging basically consists of taking the installation files, and wrapping them together, setting sane dependencies, and pre/post install/uninstall scripts where appropriate.

    Put another way, in a Microsoft world one of the single largest sources of OS trouble is third party software clobbering system dlls. If Microsoft could package that software properly, Windows would work much better. Of course, in a Windows world the third party software is actually competition, so this would never work.

    In free software the third party software is a welcome addition to strengthen the distro. See the difference yet ??

    The .deb/.rpm battle ended a long, long time ago. RPM won. How many people do you see coming out with .debs of their software? Sure, they *exist*...but at a 1:20 ratio to RPM producers.

    This may surprise you, but Debian as a distribution is still growing rapidly. And the net number of people converting from RPM based systems to deb based systems is substantial.

    But that is beside the point. Debian will continue. Its volunteer packaging force is growing rapidly, as is its user and testing base. There is no monetary bottom line affecting the distribution - only the joy of having free software that works the way it should. As long as the packagers keep packaging, the distro will continue. As long as the userbase keeps expanding, it will grow stronger and stronger.
  • No backward compatibility break between rpm-3 and rpm-4 for debs.
    Not an issue for at least RH and, presumably, other RPM-based distros (though I don't know, so I can't swear to it). RH just runs out and makes an rpm-4 compatible version of rpm that runs on old distros. Easy. Fun. Besides, presumably all the reinstalls you've had to do when the unstable Debian tree breaks your system add up to at least some form of "upgrade", hence lack of backward compatibility? :-)

    If you don't want to have to fuss with it, simply use the stable tree - that is what it is there for.

    If you don't mind the occasional manual futzing with your box, the Debian unstable tree is for you.

    And if you want a real pain in the ass, use a RedHat *.0 release. Totally unstable compared to Debian unstable. And RedHat calls it a production release.

    Don't get me wrong - I administer RH and Debian boxes. I find I spend much less time screwing with the Debian boxes, and the initscripts and cron jobs (slocate, man) do more intelligent things. Like, for example, wiping /tmp clean on every boot. And /var/run.

    Basically, I tried Debian as an experiment. It was slink, and a royal pain to install (potato is supposed to be much easier). Then it was a pain to get everything the way I liked it, as I didn't know much of apt and dpkg. Then, I used the box. And over a few months, I realized the Debian box was running more smoothly, and upgrading more easily, than the Redhat box. And this is mainly due to clean packaging and apt and debconf.

    From Debconf's own description: "It's a way to get rid of all those annoying questions Debian packages often ask when they are installed; or a way to present them to the user via a varierty of UI's.". Gee. That's just swell. Instead of auto-detecting things like most RPMs do (following a Red Hat convention) and then letting you customize things if you want something special (rpm -i blah.src.rpm, edit .spec, rpm -bb .spec), you get to manually enter stupid info that could be auto-detected 99% of the time. Lovely.

    Really, it does things like
    1) install XFree 4.0
    2) Prompt you whether you want to make XFree 4.0 the default
    3) Remind you that Debian XFree 4.0 uses the binary /usr/X11R6/bin/Xfree86 instead of /usr/X11R6/bin/X, and the new config file is /etc/X11/XF86Config-4. The new install doesn't conflict with the old one that way (since 4.0 currently doesn't work for a lot of people).
    4) Ask if you want to autoconfigure XF86COnfig-4 or use the existing version.

    So you can see, you have multiple options, all of which any reasonable user might choose. With redhat you only get a broken system until you can hack up a new config file.

    And for another example, for gdm, the debconf entry asks if you want to keep or overwrite the gdm.conf file.

    More testing.
    Again, not a .rpm-.deb issue. This is a distribution issue. If you're claiming that .debs inherently get more testing than .rpms, than I claim that you're full of it. To be fair, if you're slamming RH 7.0, you're on target.

    Really, this is critical. Debian packages get a little testing by the maintainers, and sometimes others who download them from a web page. Then, they get placed in unstable. Thousands upon thousands download unstable (since apt works so well), and an open bug reporting system checks all the bugs. The package is changed again and again until it is assumed everyone in stable can use the package without issue. Then it is moved to stable.

    Redhat is trying something similar with rawhide, but it gets a few orders of magnitude less testers.

  • The problem is that the old package simply has it s default config files, not all the nifty ones you added yourself. Downgrading with RPM can be a bit of a drag at times.

    I just compile from source--that way all the problems are my fault:-)

Slashdot Top Deals

The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra

Close