You are not logged in.
Ok, I don't mean to be flamed here. I am not advocating arch use rpms, or that rpms are better or worse then pacman packages. I have been using Arch now for several months and like it a lot! It is by far, my favorite distrobution I have tried so far. So take my question as an inquisitive person wanting to learn.
I just came across this artical http://www.linux-mag.com/2004-02/compile_01.html and making rpm spec files didn't look all that much harder then PKGBUILDs. I have had some bad experiences with rpm based distros but am now starting to wonder if I blamed the rpm packaging systems wrongly.
Arch is generally well thought out in what sort of system or methodology it decides to adopt and use (for example using bsd style init). I've read alot on the forums that archers generally have a bad opinion about rpm, but have never understoud exactly why. I always assumed it was just so much of a pain in the ass to do a spec file until I read the above article. So what were the reasons against rpm?
(cringing, waiting for the rotten apples)
-wd
Hobbes : Shouldn't we read the instructions?
Calvin : Do I look like a sissy?
Offline
my opinion:
rpm is not *bad* - it's *different*. as i hope that others will bring the arguments why not using rpm, i will try to bring also some points, why rpm is actually a great format for pkgs:
%define
%description
%changelog
%prep
%build
%install
%clean
are really great structure
it is widely spread and more than one distro is using rpm
the only feature i miss in makepkg/pacman is the %changelog - yes, it is the cvs, but often cvs-entries are not filled with enough data and it do not comes with the pkg
the discussion is opened!
The impossible missions are the only ones which succeed.
Offline
If you download an arch-package, you know it will work. If you download a rpm, it could be built for rh, suse, mandrake and whatnot. Keep it simple and clean
Offline
If you download an arch-package, you know it will work. If you download a rpm, it could be built for rh, suse, mandrake and whatnot. Keep it simple and clean
the trouble of different rpm's is, that they have different systems and architecture of filesystem, but same pkg-manager --- that's the only trouble with rpm in my eyes: either all distros with rpm should make their configs the same or each distro of them should change to a standalone packagemanager or rpm that checks what distro the rpm was built for
arch has pacman and as no other linux uses it, there is no problems with compatibility - and as all pkgs are downloaded from one server and the repos, it cannot be wrong
The impossible missions are the only ones which succeed.
Offline
Well, a couple of comments from the above posts.
1.) If pacman/makepkg were the standard, or widley used, then this same problem with exist as installed rpms made from different distrobutions. I believe this is the goal of the LSB to address issues like this.
2.) If rpms were only installed from one trusted, consistant entity then multipe packages from different distrobution would not be a problem. So the problem with rpms, according to this statement, is system maintainers misuse them. This is not a problem inherent in rpm.
3.) Despite the awesome effort of the package maintainers, packages do not always work. And when there are mistakes, they're correct swiftly . This is one of the best things about Arch in my experience. You don't have to wait 6 months for issues to be resolved. pacman/makepkg does nothing that I am aware of to keep maintainers from making mistakes, and neither does rpm.
I guess what I'm looking for is "Why does the pacman/makepkg system kick the rpm system's butt." type of things.
Hobbes : Shouldn't we read the instructions?
Calvin : Do I look like a sissy?
Offline
2.) ... This is not a problem inherent in rpm.
no, but the (mis)use of it
"Why does the pacman/makepkg system kick the rpm system's butt."
- archlinux has a centralized pkg-management system ... you cannot just like this find pkg.tar.gz files across the internet built by person XY that do not communicate in this forum but builds pkgs arch-users do not knowing about ... all is in one place and a db keeps track of all of the things
The impossible missions are the only ones which succeed.
Offline
I rarely had any problems with (u)rpm in Mandrake, my first GNU/Linux distro. As long as I used official/cooker, contrib or plf sources, everything went just fine. Just urpmi package or urpme package and it would (un)install without a hitch. It was not rpm that turned me off.
Offline
rpm is not bad ... it's different ... and it's a factor of many to switch to arch :-)
The impossible missions are the only ones which succeed.
Offline
I don't know much about rpm, just had bad experience with it. Like you say, it could have just been inexperience. I found that files installed from the Mandrake or Red Hat CDs worked fine, but nothing else ever did.
rpms are distributed independently... I guess that's the problem, like people have said. My problem with it wasn't installing the rpms, it was finding the packages that packages depended on that packages depended on that packages depended on... There has been work on this in the major distros (mandrake and red hat apparently have a central repository now?).
Dusty
Offline
the problems with rpms that they are basically "stupid" and now they are trying to retrofit them to be smart.
as mentioned earlier i also do not like the refitting of rpms to specifically be used in a specific distro. imo if a packaging is to be considered standard then it should follow standard conventions that allow the package to be used on ANY rpm distro. which brings me back to the rpm are "stupid" point. if rpms had been better designed retrofitting them for dependency solving and having a portable format would not be such a pain in the ass.
one only has to look a debian's packaging to get an example of a well designed package format that is portable to any debain based distro. all the debian based sytem use the same management with a different front end.
i always wondered why rpms were chosen as "the" packaging "standard" for LSB. despite the fact that rpm distros hold a lead in the numbers game they are not the better packages imo.
so says i dusty
AKA uknowme
I am not your friend
Offline
so says i dusty
Why are you singling me out?
I hate being singled out. makes me feel nervous. :evil:
and damn it, my name is capitalized! Don't want it confused with common dirt...
EDIT: Oh, never mind, I get it now, you were just answering my one eternal question...
I still hate being singled out though.
Dusty
Offline
as mentioned earlier i also do not like the refitting of rpms to specifically be used in a specific distro. imo if a packaging is to be considered standard then it should follow standard conventions that allow the package to be used on ANY rpm distro. which brings me back to the rpm are "stupid" point. if rpms had been better designed retrofitting them for dependency solving and having a portable format would not be such a pain in the ass.
rpms did not origionally have dependency checking? I didn't know that. Was this the case when Judd invented pacman? If so, then I can most definitily see the why he would have done so.
one only has to look a debian's packaging to get an example of a well designed package format that is portable to any debain based distro. all the debian based sytem use the same management with a different front end.
I have very little experience with making debian packages, but I don't agree with the anology. rpm isn't a distrobution, it's a package management tool. Debian based distrobutions are based on debian which uses dpkg/apt-get as it's package management tool. If different distrobutions just took dpkg/apt-get from debian and started their own base then I'd wagger that there would be alot more problems using packages from different dpkg/apt-get distrobutions, just like rpms.
-wd
Hobbes : Shouldn't we read the instructions?
Calvin : Do I look like a sissy?
Offline
rpms did not origionally have dependency checking?
They've had dependency checking as long as I've known, but never had automatic dependency resolution until recently.
one only has to look a debian's packaging to get an example of a well designed package format that is portable to any debain based distro. all the debian based sytem use the same management with a different front end.
I have very little experience with making debian packages, but I don't agree with the anology. rpm isn't a distrobution, it's a package management tool. Debian based distrobutions are based on debian which uses dpkg/apt-get as it's package management tool. If different distrobutions just took dpkg/apt-get from debian and started their own base then I'd wagger that there would be alot more problems using packages from different dpkg/apt-get distrobutions, just like rpms.
it's about level of control. Anybody could release a debian (or pacman for that matter) package that didn't fit into the Debian(Arch) filesystem. But people are smart enough not to do that.
Generally, the RPM-based distros seem to be most interested in being incompatible so they can't be interchangeable. MS tactics, but that's what happens when you're selling a system instead of giving it... Debian and Arch are open projects, that's why they work, it's why their package management stuff works too.
A package is basically just a formatted collection of files... it doesn't matter what the suffix is.
Dusty
Offline
Hi,
wdemoss wrote:rpms did not origionally have dependency checking?
They've had dependency checking as long as I've known, but never had automatic dependency resolution until recently.
rpm in itself doesn't resolve them, this job is left to a second tool like tose
which come with the most distros. I once used Mandrake which comes with
drakerpm or something like that. Whenever you open it it checks the
database of the installed and the available packages, which takes quite long.
That the automatic resolving is not included to rpm is a clear shortcoming for
me, since some jobs just needs to be done twice. Thus it is easier to brake
the system. While this has nothing to do with rpm itself it is a matter of the
individual implementation.
bye neri
Offline
Hi,
Dusty wrote:wdemoss wrote:rpms did not origionally have dependency checking?
They've had dependency checking as long as I've known, but never had automatic dependency resolution until recently.
rpm in itself doesn't resolve them
That's true.... just like pacman packages don't resolve dependencies either.
Now that the question is brought up, I don't know what makes a package *format* good... it's the tools that manipulate the packages that matter.
Dusty
Offline
I think what makes a package format good is that it has to be stable and easily usable.
For easily usable, tar.gz based packages are best, because you dont need special tools to open them. With RPMs, I need some sort of script/program to open them, many of which are not standard.
The stability part is where RPM fails. There ARE inherent flaws in the RPM package format (says it right on the RPM website) that cause an RPM to simply not install. It'll freeze up. Considering the actual package does "so little", I think making it work 99.9% of the time is really important.
"Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."
Offline
For an example of a distro that uses RPMs well, check out PLD.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
For an example of a distro that uses RPMs well, check out PLD.
no thanks i am happy with my current distro ... i don't need and don't like and rpm distro.
AKA uknowme
I am not your friend
Offline
I just wanna say that I totally agree with Sarah31!
arch + gentoo + initng + python = enlisy
Offline
I just wanna say that I totally agree with Sarah31!
uh oh. She hates that. :-D
Offline
Although I don't blame rpm directly for this, I stopped using all rpm-based distros when an rpm could not install because the package needed to already be installed to be installed. ('A' needed 'A')
=> Now known as jb
Offline
RPM is trash, don't litter...
If you develop an ear for sounds that are musical it is like developing an ego. You begin to refuse sounds that are not musical and that way cut yourself off from a good deal of experience.
- John Cage
Offline
It's just so much easier to use a centralized system like Arch. Maybe you don't have the particular packages you want sometimes, but then you can request/make your own!
I always found with RPM (using RH, then MDK, then RH, then I think Ark) that there are dependency problems. I'd end up trying to install something, then manually finding its dependencies on rpmfind.net or whatever. Mandrake addressed this slightly, and I suppose RHN should have helped as well, but it just never seemed to work smoothly.
I don't know about the state of dependency checking/resolving with RPM now, haven't used it for ages. But unless it's much more functional, it's just too much hassle!
Was much happier when I changed to a Debian-based distro.. can't remember which, and even happier again when I changed to Gentoo. Even with emerge tho, I managed to screw my system up occasionally due to not editing config files correctly.
Became a distro slut for a while, getting my hit from distrowatch every week or so, and then Arch came and Pacman sorted everything out
Don't think I'll be using any RPM distros again
Offline
Offline
I do not believe the problem is with the RPM design but more in the individual respository mantainers or builders. In the case of Redhat/Fedora, you will have no problems with dependencies IF you use repositories that use non-speccific repository dependencies. Some repositories make their specific packages dependecies for their RPMS. This is what creates RPM hell. The solution, in the case of Redhat/Fedora, is DON"T use RPM's from sources like Dag's or ATrpms. However, I have found that I can use RPM's from Freshrpms without a problem in many cases.
So, RPM is not the problem it is the creators of the fringe RPM respositories that are the problem.
Offline