Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Erm, yum can handle exactly as many packages as are in the repository *gasp* just like emerge, just like apt-get.
As for unsolvable dependencies, I've never seen one. Even if I had, there's nothing to stop such a situation occuring when using emerge. Just because a package is compiled from source doesn't make it any less possible that it will conflict with another package. If the repository is well maintained there should be no problems.
Seriously, this isn't magic people, all package systems boil down to dependency lists, source or binary, and as such all are vulnerable to the same problems.
Erm, yum can handle exactly as many packages as are in the repository *gasp* just like emerge, just like apt-get.
and the portage emerge repositry is absolutly HUGE, with a wide range of packages. and the yum repositry is.. well, lets face it.. good for getting upgrades of whats on your distro's cd's and thats just about it.
when i used fedore core 2, if a package i wanted was in yum, it was lucky...
i have yet to find a single packwage that emerge does not have in its repositry.
Quote:
As for unsolvable dependencies, I've never seen one. Even if I had, there's nothing to stop such a situation occuring when using emerge. Just because a package is compiled from source doesn't make it any less possible that it will conflict with another package. If the repository is well maintained there should be no problems.
compiled programs are much less fussy about what versions of what librarys they need. also, binarys are usually linked againsed eerything they can support, meaning they need more dependency's, but with source, you can choose option dependency's...
example... the links binary package has svgalib, libmpeg, and directfb as dependency's, but i dont need the functionality theyprovide, so compilign from source with some USE flags, and the dependency's are now more.
also.... in redhat / fedora, i frequentl got into prblems of
need to install X
X needs Y version 2.6
i have Y version 2.58
attempt to upgrade Y fails becase other programs require Y version 2.58
this cannot be resolved without riping my system apart and putting it back together.
Quote:
Seriously, this isn't magic people, all package systems boil down to dependency lists, source or binary, and as such all are vulnerable to the same problems.
but some, (like rpm) use human written dependency lists... which arnt always perfectly correct, other package managers like slack look at ldd output.
1) yum repositories are easilly added to yum.conf. e.g. the dag repository is enormous.
2) I take your point about being able to chose which components you need if you're compiling from source. Fair enough - this is an advantage with compiling from source, but it's still not a case of simply 'emerge name_of_app' if you have to dive in and change configure flags. Admittedly you don't get this option at all with rpm. You win on that point.
3) Maybe I've been lucky, but I've never seen a spiraling dependency problem like you describe when using yum, and there's still nothing to stop this happening with source compiled packages.
4) I wasn't aware that slack packages analysed ldd's output. That seems like quite a good way of doing things. Makes me wonder why this sort of thing isn't done for RPMs. In fact this seems so obvious that it makes me wonder if this isn't how RPM packages are packaged anyway. RPMs are quite able to display exactly which .so files are needed, so I wonder where they get this information from. ???
It seems to me that the problems RPM has are pretty much the same as the problems all packaging systems have *unless* you're willing to wait for source packages to compile and are willing to modify configure flags if you run into dependencies that you're not willing to satisfy, which sort of defeats the purpose of packaging, don't you think?
this happened to me in windows, not linux. byt when i installed gaim, it came with gtk version 1(hypothetical number) and when i wanted to install gimp, it required version 2. so i go and install gtk version 2 over 1 and then gaim dosent work any more. i think thats what hes talking about with spiraling dependancys.
in the end, i solved it by installing gtk2, then gimp, then gaim, and choosing keep the current version of gtk.
i like apt, it just works and it works well. ive never had any problems with it. and when i cant find a package (very rare) i dont mind compiling from source. when i was using mdk with rpms however, i actually prefered to compile from source instead of using rpms.
in the end, i think that portage and apt are the only two worth package management systems.
im thinking of installing gentoo instead of debian because of portage. ive heard that you can use it to install ati drivers. ive been having problems with those in Mepis. however, mandrake was even worse when it came to ati drivers.
Those saying how good source-compiling is, and how emerge is even better, should realize, that dependency-tracking is not only checking that all needed software is present when you install. It is also checking that uninstalling something won't do any harm.
[/quote]yum repositories are easilly added to yum.conf. e.g. the dag repository is enormous.[/quote]
true, but it does require a little extra work...
for example.. http://quakeforge.net
as i remember, yum with default configs cannot install quakeforge.
and the quakeforge websiite has no mention of a yum respositry, at this point, it would be easyer to download the rpm, and any dependency's manually.
in this sence, i would consider yum to have failed on supporting this packwage, even though that somewhere out there, there may be a games reporisty i do not know of.
Quote:
3) Maybe I've been lucky, but I've never seen a spiraling dependency problem like you describe when using yum, and there's still nothing to stop this happening with source compiled packages.
to be honest, i was installing some exotic software... cant remember what, but maybe this was the fault of the package creator.
Quote:
4) I wasn't aware that slack packages analysed ldd's output. That seems like quite a good way of doing things. Makes me wonder why this sort of thing isn't done for RPMs. In fact this seems so obvious that it makes me wonder if this isn't how RPM packages are packaged anyway. RPMs are quite able to display exactly which .so files are needed, so I wonder where they get this information from. ???
normal pkginstall doesnt... but swaret, or whatever its called does.
its possible that rpm's use ldd's output, but documentation on 'checkinstall' surgested dependency lists were written by the author....
come to think of it... the author probably uses ldd to write the list.. so maybe this point was not valid.
There ARE limitations and downsides to all package management methods.
emerge's main downside is the time it takes to compile some things.
and its advantage is all the advantages you get from compiling from source.
for me, this tradeoff is great, i dont add new software often. but i can see how for others, the cipile time may not be acceptable.
i suppose the *best* package manager is the one that fits a users particular needs.
Originally posted by qwijibow just explaing my reasons for not liking rpms
a poll without reasons or explanation is just... boreing.
Well, its okay to give your reasons and what you use, why you think its better.. but to some I only feel this is going to start a war. Read, Answer the question and get out, no need to stick around IMHO..
lol.. sorry to argue, and i know im tempting fate here....
but ...
i give my reasons.. etc...
some1 else gives oppsing views...
then we discuss, each others points of view, and come to some kind of agreement.
and boom, we have a discussion (and hopefully no flames)
anyways, i think the discussion here is pretty much over.
so far, i think every1 has behaved, no flames or flme bait, just a load of politly and respectfully put, valid points relevant to the poll.
hehe, i argued with a mod... twice in one day! this thread is soooo lcoked.. sorry guys, couldnt resist
I like rpms coz they save me time when managing software on my system. Urpmi, apt (seems to work the same like on Debian based distros) and yum, seem to do a very good job of managing packages. I have never had any dependency problems on current versions of Mandrake and Fedora, because they have been automatically resolved. Compiling source is fine but can get a bit tedious and time consuming.
RPMs need some work. Can you get emerge for FC2? I would like to try something that works a heck of a lot easier than yum, apt (not installed yet!) and rpm.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.