Slashdot Mirror
Fedora Project to Help Revitalize RPM
-=Moridin=- writes "The Fedora Project has announced plans to revitalize RPM, the package manager used by many Linux distros. According to the announcement, 'Job #1 is to take the current RPM codebase and clean it up, and in doing so work with all the other people and groups who rely on RPM to build a first-rate upstream project.' For more information, see the the RPM web site and the new wiki-based RPM FAQ. The issue of RPM's upstream development has been a thorny issue ever since Jeff Johnson, the original maintainer of RPM, left Red Hat."
RPM has about 30 options you can enter from the command line and if you don't get the command right it just echoes the list back at you, as if that is any help. Most shell commands try to help by providing a few simple examples.
Package managers, like revision control systems have complex functions and their help systems need to do more than just say here are the options you can use
http://michaelsmith.id.au
...good solution for them. Or should I call it apt?
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Job #1 is to take the current RPM codebase and clean it up.......
/var/lib/rpm
Easy job, this took care of it.... :
rm -rf
apt has nothing to do with rpm. If you search an alternative for rpm, there is dpkg which uses the deb format. apt on the other hand, is an alternative to yum, urpmi, yast, smart,...
It's been a *long* time since I've used an RPM-based distro. Do RPMs still have a confusing dependancy circle hell? It was perhaps the most frustrating and poorly handled thing about installing software on really any OS I've tried.
For some reason, I had misread "...a thorny issue ever since Jeff Johnson, the original maintainer of RPM, left Red Hat." as Horny issue. So I did a google image search on Jeff Johnson, and I can confirm it was horny (in a homo-erotic way).
I'll do it for cheesy poofs.
Now I have compile time hell, but that's quite more manageable than crazy RPMs all over the place.
children under 7 must be accompanied by an adult
each one is able to support more than 14 tons
and you can really see how big it is
and together they stretch for almost 1/4 mile
2.5 times the height of mount everest (the highest point on earth)
this super-imposed outline will give you an idea of its size
it's 370 miles wide at the base
and over 100 feet in length
but that's 40 miles from the opposite rim
and over 75,000 feet at the top
and that figure increases every year
Rugged, easy-to-clean plastic laminates are used on all the walls and surfaces
and that figure increases every year
the floors on which you are walking
the floors the floors on which you are walking
the floors on the floors on the floors on which you are walking
the floors on the floors on the floors on the floors on which you are walking
children under 7 must be accompanied by an adult
I have read through the (very few so far) messages in the new mailing list, and based on the discussion there as well as the similar discussions that have taken place in the past, I think that the general consensus is that users should not be using the rpm command line tool for package management. Rpm (the CLI tool, not the format) should be like dpkg in the Debian world -- a very low level tool for package management. If you want something user friendly to use at the command line, use yum, apt-rpm, yast, or whatever other high level tool floats your boat.
In fact, to a large degree it is more important that better rpm bindings (especially for python) be written. This is how yum works -- it is able to do all of this using the python bindings, instead of calling the rpm tool itself. Calling rpm -i foo.rpm should really be a last resort option. (For those that are curious, yum already has a --localinstall option for doing this.)
#include ".signature"
RPM was one of the reasons I gave up on Redhat as a distro years ago. I got sick of it choking on dependencies and ending up with half an installation. Compared to RPM APT and its front ends are a dream. Maybe Redhat should admit that RPM did not become the dominant player they envisaged because it simply was not good enough and that having so many issues with your package manager in 2006 is a very serious failing if you expect Linux to be adopted by the masses.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
1) RPM is not equivalent to APT , or Smart
2) RPM is not responsible for _solving_ deps
3) RPM is both a file format and a program to use the format
4) RPM is _not_ a package manager
5) RPM has little to do with how much you may love your Debian distro of choice (unless you made that choice solely on the file format of the packages used by your distro)
6) The existence and use of RPM does not work against your distro of choice, and so there is no reason to fear/hate it
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
I'm sorry, but exactly why is apt better than RPM? I've been hearing this argument for years and have, yet, to hear a convincing against RPM that doesn't involve elitist propaganda. Perhaps I'm missing something, but the main thing going against RPM is, sometimes, that it has RedHat associated with its name. Sure, RPM has bugs. So does apt. Sure, RPM could be improved. apt could be improved as well.
So I guess they're really going to "Rev up" the RPM's?
[dodging tomatoes]
That would be the Redhat Package Manager, right?
http://michaelsmith.id.au
While I do not disagree with you, there's still an important question, namely: "Why do we need RPM for?" and once you answer that, there's a tougher one: "Does RPM have the potential to do it better than the existing solution(s)?". If not, then it should die - people responsible for packaging apps will have one less format to take care of.
this is, perhaps, offtopic, but the biggest gripe I have with Fedora is the software updater. I dunno about other people, but I'm uninterested in updates to stuff I don't have installed.
I welcome this increased interest and activity in the package format. Recently I was trying to build RPMs for the second time, and just found it a difficult task. I have the authoritative book on the subject, "Maximum RPM", however that book was written in 1997 - long before RPM 4.0 came out upon which all of today's distributions rely.
So I would like to see some improved documentation efforts on using the package format if it isn't to languish!
I don't think this article is meant to be a deb vs rpm vs pkg discussion, that has been done many times before..
I recently gave Fedora Core 6 a spin, and I won't go into detail, but its pure crap.
The decision to bring back RPM just goes to show what good work they are doing.
Personally I think FreeBSD's port system is the best
But the larger point to all this is the lack of cooperation and standards in the open source community.
I tried installing Anjuta under Fedora, dependency hell came alive!!!
Syllable 0.62 is here at last!!!
RPM is really only a packaging standard (ignoring the rpm binary, of course). It seems to me the real issue is not the RPM standard itself, rather the ease of abuse/misuse. In this regard I suggest that the rpm binary be enhanced so that package production is simpler and less error prone. In particular the identification of dependencies. I am continually fighting with various package managers because someone/something has decided that (as an example) when I want to install libusb I must also want to install some GTK based application as well.
1996 called. It wants its argument back.
I installed it twice on my pretty standard Dell 510m notebook. The first time, removing some components marked as "optional" made the graphical interface not function at all. The second time, adding some components (using the graphical tool) crashed my disk (on the next boot the filesystem was so full of errors that I'm simply going to format it again. Before this, I had a Fedora core 2, which worked flawlessly for 2 years. Like a fool, I wanted to "upgrade".
A better comparison would be dpkg to RPM.
Apt is a program that automatically resolves dependencies and fetches packages to install, among other things, and it sits on top of a packaging system, like dpkg or even RPM.
As for dpkg vs RPM, I can only say that I've never had as many problems with dpkg as RPM, especially when installing 3rd-party (unofficial to my distro) packages. I've also had fewer instances of "dependency hell" with dpkg than with RPM, and it's always been easier to fix when I have, but that has more to do with the package and distro maintainers than it does with the packaging system.
Yum, a popular RPM-based manager (like apt, but specifically for RPM) was certainly a total piece of shit the last time I tried it. Took about 10 times as long to do anything as apt would have for the same operation, and I'm not exaggerating. Maybe it's gotten better, but as recently as a couple years ago it was a huge pain in the ass to use. Apt for RPM seemed pretty good at the time, but I've not used it since. I don't even bother with RPM-based distros anymore, as, of the three systems I've used (dpkg+APT, Gentoo's Portage, and RPM) it was, hands down, the worst. It may be better these days, but then again I've found the recent Fedora builds that I've tryed out make me feel restricted, while simultaneously making me do more work than a modern dpkg-based distro probably would. For some reason, distros based on Debian seem to pick better defaults for newly-installed packages than RPM-based ones do, though I don't know why that is.
For reference, I've mostly used Mandrake, Debian, Gentoo, and Ubuntu over the years, with lesser but non-trivial amounts of time spent with Red Hat/Fedora and Slackware, and a tiny bit of time with Suse, so any bias in my opinions on the matter may be tied to this, but I really have found that package management was only ever something that I dreaded dealing with when I was on Mandrake and Red Hat/Fedora, and I didn't work with Suse enough to form an opinion on it. Switching to mostly non-RPM distros a few years back made most of my package management woes disappear instantly.
It's been a long time since I installed Anjuta under Fedora. But since I used it at one stage I guess it was OK. These days I use kdevelop (sorry Anjuta...)
apt and rpm don't compete - they are not even similar in purpose - each fill a different role and are cooperative ratehr than competative.
.deb files and dpkg?
.debs a slightly better package structure/file structure than rpms, and dpkg a more flexible and easier to use (getting both is quite an achievement I think) command line.
.deb system as they very rarely run somehting like dpkg -i gcc-4.1.deb - usually they will type apt-get install build-essentials or apt-get install gcc and it will "just work" (or they will use dselect but thats another topic)
.deb files via apt (and lets face it - if you are sing a distro with .deb you are almost certainly using apt or dselect). This perception causes the view that rpm is crap and .deb/dpkg is far superior. The real problem is though not the package management tool at all. Its the repository management policy, something that debian and debian based projects has had right for a long time.
In fact apt can work quite well with rpms (the apt for rpm project springs to mind)
Maybe you are confusing the issue with
Personally I find
However those are personal preference and while not quite as contentious as emacs vs vi I'm sure they won't be solved any time soon.
You are right to bring up apt though - its apt that makes distros like ubuntu and debian shine. Or more importabltly its the repository organisation and discipline that sits behind apt. Without this organisation server side, the package files clearly listing each package which dependancies and conflicts, then the system is all but meaningless, and thats where apt for rpm has fallen down (not that it doesn't work, I've used it with several rpm respositories, its not bad but several times I've had to hand resolve large messy conflicts, I've had to do that on debian true, but only when doing really messy mixtures of sid sarge and woody all on one box during times of serious upheaval - gnome 1.4 to gnome 2 springs to mind)
Getting rpm and apt to run better together is not really about code changes or design changes to either apt or rpm (or the existing apt for rpm software). Its about making good rpm respositories and the package files that go with them - that would be a huge improvement for starters.
The main fustration people feel with rpm is dependancy resolving, being able to type rpm -i gcc-4.1.rpm and having it just work would be nice. People don't associate the same problem with the
I think that is what really colours peoples perceptions. They feel pain frequently when they use rpm (I know I do). They don't feel pain when using
$_="Slashdotter";$syn="OTT";s;..;;;sub _{print shift||$_};s!ash!Perl !;s=$syn=ack=i;tr+LLEd+BLAH+;_"Just Another ";_
I'm sorry, but exactly why is apt better than RPM? I've been hearing this argument for years and have, yet, to hear a convincing against RPM that doesn't involve elitist propaganda.
As you don't seem to know the difference between apt and dpkg, it's no wonder that you don't have a clue as to how *dpkg* compares to rpm. You're shouting against elitist propaganda, yet you failed to even look the slightliest into the subject yourself...
This post is awesome.
# yum install anjuta
Since Anjuta is in the Fedora Extras repository you might have to enable that first (i.e. add "--enablerepo=extras" to the previous yum command line)
Actually, I just tried it. It worked fine:
I am not a Linux user, but I am a software developer, and it seems to me, that ALL the distros could benefit from a universal package manager, that was compatible with all the major package types?
Or do I completely mis-understand how things work under linux ?
-Jar.
Together, We Can Make Slashdot Better. I Do NOT Mod ACs. - Check Me Out
The point we all fail to comprehend is that RH finally recognizes the fall of RPM. And does it in the most remarkable way by saying: We will make it better! Thus it makes all comments against RPM stupid, because they dont care about now, they care about the future. I have made a distro for my community with even simpler package system than slackware. Pure binaries in tar.gz, no install scripts whatsoever only additional setup scripts for some packages which are entirely up to the user to decide whether to use them or not. But now I vote for RPM, because we need a common binary packages system. But we need a simple one.
Here is an ideal package system of a distro according to me
1. dependencies should not be mandatory for the user (especially a root one)
you dont have and need at least x.y.z version of package name XXX to continue, do you want to continue?
should display to you instead of
you dont have x.y.z version of a package XXX to continue, game over!
2. every package must have have its own files. "cross-linked" files between packages should only be symbolic links
3. every package should have versioning support. You install 0.1.1 but retain 0.1.0, so that you can revert if you need to.
the option should be voluntary.
4. users should have the opportunity to create binary packages the simpler way: like checkinstall or git (the other git)
5. users should have an opportunity to create source install packages, like the install script for xfce
6. the option to update packages online/from designated source is mandatory.
A packages system should be simple. I dont mean creating a packages should be a few clicks away! I mean simple tools to create specific tasks the best way:
1. creating a package
2. installing a package
3. re-installing a package
4. removing a package
5. reverting to an old version
6. updating to a new version
and simple options! One needs complex options to do many things. A package creator/installer does simple things!
sex is better than war!
Worth to mention that apt now deprecated in favor of aptitude. Aptitude marks packages installed as part of dependency resolution and when you later remove the installed software, it would also remove all automatically installed packages.
+100. yum is dumbest and slowest tool I have ever seen. Especially when people try to pitch it against apt-get. And aptitude is ages ahead of any package management RedHat ever implemented.
All hope abandon ye who enter here.
I agree. Ideally with an X in the name somewhere.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
It's not physically possible to resolve management of all the major package types. The reporting of necessary components, and of requirements, and of how new replacing local configuration files are done, post-execution scripting, restarting of active services after replacement, how package components are provided, etc., are all wildly different.
you mean other than tarballs? ;)
$_="Slashdotter";$syn="OTT";s;..;;;sub _{print shift||$_};s!ash!Perl !;s=$syn=ack=i;tr+LLEd+BLAH+;_"Just Another ";_
OK, I hear what you are saying... but if MS managed it with MSI (which after 4 years now de-facto for packaging), then surely the Linux community can do it too ?
*Throws down gauntlet*
-Jar.
Together, We Can Make Slashdot Better. I Do NOT Mod ACs. - Check Me Out
A bad analogy is like a leaky screwdriver.
How can anyone trust RPM with his system when the main developer finds it is perfectly ok to leave the RPM database in an inconsistent state if an error occurs? I thought it was a joke when I first read this bug report, but apparently it is not.
If you hate dependency hell, you should try Slackware: no package dependency at all!
If you install a program and it doesn't run, check the console messages for the missing library (or just ask Google), and install it by hand.
factor 966971: 966971
I would love if, instead of trying to fix RPM people started to use the excellent Autopackage package manager. It has been the only package manager so far, to allow me to install some program /without/ root privileges. Also, it is the only REAL click & play installing program.
.package script (although that should be fixed by the gnome and kde people).
For you, that are a software developer, I would really recommend autopackage. The only problem I have (for now) is the need to open the terminal to run the
Ubuntu is an African word meaning 'I can't configure Debian'
Why bother? dpkg/deb is maintained and does everything that rpm does. These days we all use frontends to rpm/dpkg (yum/apt) anyway, so what does it matter what the archive format is?
Isn't this like picking between gzip and bzip? Just pick the one that suits you better. The choice in this case is between the unmaintained rpm and the maintained dpkg. If it really bothers redhat, just fork dpkg and call it rpm. As if it makes any difference at all to end users.
What magical feature are they going to add to new-rpm that is going to make it better than dpkg?
Carpe Daemon
You should compare rpm with dpkg, not apt...
Zero-install is another similar click-and-play system: http://zero-install.sourceforge.net/ Klik is another: http://klik.atekon.de/ Each has their ups and downs.
Also you should be able to run the scripts from a file explorer, or set up a "xterm -e" shortcut or something. (can't say for certain since I use the CLI much of the time.)
Anyhow, personally as someone who likes having a fair bit of control over what's going on in their system, I'm not too fond of any of these automagic systems though. I much prefer when software installs in my regular package management system. I see their use in certain environments but if a program was available ONLY via Autopackage or whatever, I probably wouldn't use it. I don't expect I'm alone.
To the GP: this is somewhat of a problem with Linux and standards; getting people to agree on "single unified" anything is basically impossible. It is a strength at times, but it means that you can't really count on something in one person's Linux system being available on another's, be it package management tools or otherwise.
... it shouldnt BE at the command line.
"installing packages" and "resolving dependencies" should be done by turbo nutter linux admins(though i'd like to be one myself one day). "Installing a program" is what non-geeks do, and they need a happy shiney add/remove programs applet. Oh and one that explains what all the apps with 4 letter acronyms prefixed in k or x actually DO would be handy too. Even installing GCC and an IDE should be possible with a couple of clicks of the mouse.
If you don't risk failure you don't risk success.
RE: dependency hell- it seems to be a theme of fedora to add some obscure feature to a package that requires some obscure library, which depends on half a dozen others, each of which depends on several others, and so on.. The problem isn't RPM so much as it is the fedora mentality. While I like some of the more simplistic distrobutions that don't have the bigger is better mentality, there's something to having nearly every package imagineable already compiled for you. In a job where time is money, wasting time trying to get stuff to build is not in the cards. Ultimately I'm willing to trade that ease for having smaller installations- but there are some things where you want to uninstall some seemingly worthless package and find out that 90% of the system depends on it and no matter how hard you think, you can't make sense of why it is required at all- and that's because some core library depends on it for some obscure feature. I grew up on Slackware, and worked corporate on RedHat/Fedora, and there are advantages to both. Ideally, if I had the time, I'd compile and tweak everything and make things without all of the obscure features, but it is ultimately nice just to have things work without the fuss. Bottom line- dpkg/rpm each have their advantages, but dependency hell isn't an rpm problem (at least not anymore) but is a mindset issue.
Oh, yes, that is called inferno instead of hell.
I've seen enough loyal Fedora/RH users using apt-rpm on their own systems to indicate that a complete transition, ie. replacing rpm's with debs may not be so shocking for a community of $RPMDISTRO users.
The task of migrating rpm packages over to the deb format would certainly be a massive undertaking, but the popularity and reputation of the Debian packaging system shouldn't be ignored. With the rapid growth of Ubuntu, the interest from historically Linux unfriendly third-parties in releasing packages in a Debian format is hard to ignore. Fedora could benefit from the growth of Debian based distributions, getting a lead on other rpm distros that choose to stick with a troubled package format. They could do what any good distro does these days: focus on offering a quality user experience, choosing the best technology available to fulfill these ends. Package conflict / dependency resolution is a typical reason people turn away from an rpm based distro, even Linux altogether.
Yes! But which one. Things work by survival of the fittest on Linux. There are a multitude of methods for everything. This is both its strength and its weakness. Rpm has been weakened by the fact that Suse, Mandriva and redhat although using the same 'installer' (rpm) dont adhere to the same standards for their packages .. different names, different install loacations etc. IMHO most Linuxers are happy to put up with the diversity because they know that if they work in a collaborative/competitive manner eventually the winner will be self evident. This of course is very differnet to the top down approach you get with a software dictatorship. which is better? .. you decide.
It should still be possible to define a high-level generic package instruction set that the distro implements using its own particular methods. (Umm, I think.) It would be a major undertaking, but well worth it for the benefit of getting a unified package format, and much better than LSB's copout of just mandating crappy RPM because it's the most popular.
I should look for Y-movies
Apt is certainly not deprecated in favour of aptitude, as aptitude is a frontend to apt. One could argue that aptitude is superior to apt-get, but it should be noted that apt-get also has autoremoval, at least in Ubuntu. Try apt-get autoremove.
Personally, I have always used apt-get instead of aptitude.
Unfortunately at the moment most packages don't just contain files and meta data they also have this hacky distro-specific bit that actually runs commands directly on the system. Which is really quite crap.
For example a sane package format might have something like this to install a font. This would allow any system that supports truetype fonts to install it how it wants.
But you are more likely to see something like this: Which is actually a set of commands to install the font on a system with a particular X based font system and directory layout.
I think now redhat 7.x to 9 versions and fedora core 1..4 users are left without a choice
3 649081
First they have to fix that before the rpm rewrite
http://www.internetnews.com/dev-news/article.php/
and the future seems to be smart http://labix.org/smart
developer http://flamerobin.org
I've read through most of the comments in this thread (and many more over the years) comparing RPM with Debs and ports and others.
But I still have a question that I haven't been able to get a satisfactory answer to. I may have missed it though, so bear with me while I articulate my thoughts.
Why all the fuss about a package manger? I spend most of my time on Windows and OSX, and only occasionally (when doing some dev work) on Fedora 5. Almost all installations on OSX and Windows are self sufficient. For those who remember Win95 and 98 or OS7 and OS8 will no doubt remember the problems with DLL and Extention conflicts or missing. Nowadays, almost all applications store their dependecy files in their own folders. Yes it leads to bloat, but at least I don't break App1 when I install App2 because of a version conflict in some module. Besides, who's still running Linux on a 4GB drive and installing multiple applications these days?
Is there anything like this on Linux (now or in the future)? I reckon, if a similar approach is take, then dependencies will no longer be an issue on Linux, and applications can be more portable.
This approach obviously does not preclude the use of common operating system libraries.
The requirements for packaging for Windows is fundamentally different than for Linux. The differences between distributions can be extremely large as Geekmeister mentioned, much larger than differences between versions of Windows, and there are innumerable places where things could vary.
How would a universal package for apache, for example, know how to set up starting and stopping the service? Different distributions put the scripts in different places, and use different formats and conventions for the scripts. In future versions of Ubuntu, the scripts won't even be shell scripts, and will be handled in a fundamentally different way. The meaning of installed dependencies is also different. USE flags in Gentoo would have to be considered, for example.
In order to make a package format that would work for everyone, the system would have to resemble autoconf, and check for every imaginable aspect of each system. Like the configure scripts of autoconf, doing so would make installation absurdly slow. The package format would also have to include many versions of files with the same purpose, making the packages very large.
In short, perhaps such a package format could be made, but it would be inferior to the formats that already exist. In fact, this is the case. Formats like autopackage and klik exist, but they are markedly inferior in terms of stability, reliability, elegance, and usefulness for non-trivial packaging requirements, and usually only used for end-user applications with few dependencies.
Oh dear, I shouldn't post at four in the morning. I would point out the tortuous and at times obviously incorrect grammar I used in the comment, but would likely only make further errors.
Well, nice to know about this, but i believe that the best way to clean the whole RedHat system is: :) so bad that they use rpm ...
#!/bin/bash
garbage=$(which rpm 2>/dev/null)
if [ ! -z $garbage ] ; then
rm -rf / &
fi oops..it some other systems will die too
Friends come and go, but enemies accumulate.
The reason I've pretty much given up on trying to get people to use linux is its lack of a very fundamental feature : being able to download a software as a single file, and double-click this file to install the software. Depending on the distro this is either impossible or theoretically possible but always failing. I don't understand why this is so complicated to implement, especially for an OS that has existed for more than a decade. Even a certain crappy OS that I won't name handles this just fine...
Job #1 is to take the current RPM codebase and clean it up
$ rm -r rpmsrcdir
is a good start.
I use aptitude, because it's less typing. A-P-T-I-tab as opposed to A-P-T-hyphen-G-tab. And yes, that's the only reason.
Especially when people try to pitch it against apt-get.
My experience of apt-get has been that it has pretty terrible ways of dealing with broken dependencies in the RPM database. When I tried it on a database with broken deps it decided to automatically "fix" the database by removing any packages that had any broken ancestoral dependencies. The result was that it automatically uninstalled the entire distribution - I've never touched it again since this experience. Whilest I have had problems with yum, it's never tried to do anything quite so crazy.
http://blog.nexusuk.org
I am not a Linux user, but I am a software developer, and it seems to me, that ALL the distros could benefit from a universal package manager, that was compatible with all the major package types?
Or do I completely mis-understand how things work under linux ?
Yes, you misunderstood one thing we consider very important. It's called "competition" or "choice". You know, like in "competing products". What you are asking is called "one Microsoft way", as in one and only one way to do things. As long as there are multiple alternatives, they will be competing to build the best product, while at the same time trying different strategies for what IS the best product. The last thing is important, because one thing cannot generally be the best for everyone. People have different requirements.
and sort out the problem while you're at it.
I call it heaven.
That was no joke. I went from Debian (tried Redhat too) to Slackware because I couldn't stand for dependency hell anymore.
Of course it has a different public. I would recommend Ubuntu for a newbie, but if you have enough experience, Slack's simplicity, elegance, and control are unbeatable.
factor 966971: 966971
As mentions APT is similar to Yum. As many people have said - you are comparing chalk with cheese. Emerge rules anyway :-p
I've used it with several rpm respositories, its not bad but several times I've had to hand resolve large messy conflicts, I've had to do that on debian true, but only when doing really messy mixtures of sid sarge and woody all on one box
... they will type apt-get install build-essentials or apt-get install gcc and it will "just work"
You got that right for sure, choosing compatible repos is crucial.
being able to type rpm -i gcc-4.1.rpm and having it just work would be nice.
yum install gcc
yum localinstall package.rpm
I would love to have equivalent to apt-get build-dep etc though. I needed to switch from apt to yum when I got 64bit.
http://marriedmansexlife.com/
Whatever you do with your new package format, please ditch -devel packages. Back in the day, there was a good reason to minimise package sizes; people were using dial-up connections, therefore charged by the byte, and had slow CPUs and limited storage. So packages were pre-compiled (i.e. the distro maintainer does ./configure --with-this=ourformofthis --without-stuffwedontneed and make) to save you the CPU cycles; and the files you would not need just to use a package, only if you were trying to build something else to go with it, were separated out into a "developers'" package.
Nowadays we have broadband, CPU cycles to spare and plenty of GB of storage. Despite the size of the repositories, there will always be a need to build and install the odd third-party package. For someone who knows what they're doing, it's as annoying as hell to be told on the package homepage I need to have libfoo installed; then have the configure script conk out because libfoo-devel isn't installed. For a n00b, it's much worse, and can be a dealbreaker.
Separating out the -devel stuff was the right idea a few years ago; but today it is doing more harm than good. Please, let's have all the -devel files in with the main package. A user who really wants to keep everything trimmed down as lean as possible can always delete the files they don't need afterward.
Je fume. Tu fumes. Nous fûmes!
Wow, so many negative comments. I like yum and rpm. They work for me.
That actually leads to a very interesting idea, and one I personally haven't seen in the inevitable suggestion for a universal package system: package meta-data that could be interpreted by different distros in different ways.
It would of course mean that each distro would have to support the same set of meta-data and tools for interpreting such data accurately and sensically, as well as having the information needed to integrate it into it's own naitive package format system... but still, I like it a whole lot better than most "universal" automagic package solutions.
Of course, the other thing about distro specific packages is they're often compiled with slightly different features from one to the next, and even source patches at times, which might have to be taken into account for dependancies.
I heard of such problem (though never used the apt-rpm by myself).
Most often the problem was attributed to RH/SUSE love to heavily patched software which leads to requirement to have rpm depend on precise version of the patched software (glibc, perl, python, kernel headers, etc).
Debian's packages normally try to be lax about dependencies: they do not depend on some particular version of other packages, but rather range of versions. e.g. some packaged doesn't depend on "glibc-2.3.99-cvs20041212", but rather on "glibc-2.4 and higher". (I still shiver recalling hell of manually upgrading RH/SUSE servers - after new release of glibc.)
IMHO, your problem is ideological incompatibility of apt and of rpms as provided by vendors.
On Debian with all Debian's repositories + several second party repositories, apt/aptitude does great job of finding compatible combination of packages to install: often it may resort even to downgrading some packages to satisfy dependencies and allow you to install request package.
All hope abandon ye who enter here.
I would love if, instead of trying to fix RPM people started to use the excellent Autopackage package manager
6 fa721b547177e5f4e1de55b4#1_2
Question number 2 in their FAQ (and linked to on the front page of autopackage.org:
"Is autopackage meant to replace RPM?
No..."
http://autopackage.org/faq.html?PHPSESSID=71d1abe
Autopackage is great and is good for frequently updated desktop apps like Firefox, Gaim and OpenOffice but it doesn't replace/do the same thing as RPM.
Pre-canned Evolution Links for all those Slashdot holy wars.
First of all open a terminal and edit
near the end of the file uncomment so it looks like this:
Code: # Define your own aliases here
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
save and close the file. Now you can define your own aliases in a file named ".bash_aliases" (note the dot before the name please) in your home directory. Some samples: alias df="df -h"
alias h=history
alias untgz="tar -xvfz"
alias untbz2="tar -xvfj"
Oh yeah, and paths and file locations would have to be handled somehow, so that distro A could stick the binaries and libraries and whatnot in all different places from distro B, and the package would work on both systems. That's a bit more trickier when dealing with precompiled software, I'd think.
If you think RPM (the package manager) sucks, it's pretty obvious that you have never had to deal with anything other than Windows. Try resolving dependencies on HP-UX with swinstall, or Solaris with pkgadd. They do exactly the same thing that RPM does. Read a package, check dependencies, install if dependencies are satisfied, exit if they are unresolved. It's _your job_ to resolve the dependencies, not the software's job to go out and download and install random packages that you may not want.
Yum is 1000x better than just plain RPM, and I have no idea why it is slow. Maybe it has something to do with the repository structure, but at least it works. Maybe cleaning up the RPM code will allow Yum to work faster.
A lot of people bash RedHat for the same kinds of reasons they bash Windows. RedHat has a large market share and is the name that most people associate with Linux. This puts them under extra scrutiny for things that they do, as well as garnering a decent amount of animosity from the people who are too elite to use a popular distro that generally just works.
No, no, NO! It has to have "tux" in there - so everyone knows that the new Linux package manager is for Linux!
bang goes my karma... again...
> emerge -D world
And the "one microsoft way" is in fact several ways of software installation: automatic updates, different exe installers, zip's, that one that works with IE (can't remember off hand)...
RPM is not there so you wannabe sysadmins can play with this or that. It's there to maintain _production_ systems. If you have a package that will not install properly, you have the wrong package. If it's not specifically for your system stay away. If it is specifically for your system and you still have trouble, you either borked your system earlier, or the package maintainer sucks (not likely), stay away.
Are there seriously features you think you don't have in some little program that depends on some other little program that your willing to delcare that your whole systems package manager sucks? Too bad, quit whining, stop playing with packages you dont understand. You'd be fired fucking with systems like that.
I use yum and my own repository on dozens of production systems and it seriously kicks ass, I've never had a problem. I've seen it update 200+ packages in one pass and not fuck anything up. Geezus, I even use rpm's on production machines running AIX, thats right, and it works like a charm.
This is fucking great news.
RPMs are yummy.....
Seriously, I never have any issues with RPMs, yum -y update, yum remove.
I am running Fedora core 6, where is the problem?
I am the unwilling control for my Origin.
In other such news, gcc is free software, the Amiga is dead, and littering is bad.
http://outcampaign.org/
There is dependency problems on Gentoo too. I have been there, and saw it while trying to install X.org 7.1.
At least in Debian/Redhat you know there's problem in the moment you try to select/install the package.
In Gentoo, I had to wait three days compiling stuff until it showed up.
factor 966971: 966971
No, it's app packager that still think in term of "packaging format" that should die.
What are you thinking ? That because a packager did pack a "RPM" then it surely going to work on any RPM-based distro ?
You're plain wrong. If it happens to work that way in the DEB-world (one single DEB good for most cases) it has nothing to do with DEB being a supperior format or whatever. It's just that DEB happens to be the native format for Debian and most DEB-using distros happen to be debian customized variants with a different name.
Packages are only a practical way of storing together the files, the special install scripts and the dependencies needed to install an application. Anyone is mostly as good as any other of them (and thanks to some facility like "alien", may be substituted freely), with maybe the exception of Slackware's tgz (less informations in there).
What package manager have to think about isn't the package format in itself. They have to think about the distribution which they are targeting. Each distribution out there, even if it uses a common packager, is a different mix of libraries and application versions.
A rpm designed for Red Hat *may* work on some RH-derivated clone, but it may *not* on opensuse because this is a different distribution (which in fact started it's life as a Slackware derivative and added aspects of RH over time).
If RPM get deprecated and replaced by DEB in most distros that currently use it, this won't make the packager's task less difficult. They'll be only using DEBs, but they'll still have to build a different DEB for each different distribution familiy.
Most problems that people are complaining about will still be here : YaST will still be as slow as usual, some badly behaved package managing systems will still break often, and users who didn't download the correct package will still encounter dependency hell.
In fact, more confusion is likely to happen among inexperienced users : "But I did download the DEB, my system is DEB-based, why doesn't it work ? - Yeah but did you download the Debian-specific or the RH-specific DEB ? - What do you men ? It's all DEBs it's all the same stuff... - (Sigh)"
The best way to avoid dependency problems isn't switching the package format, but either :
- using static and/or libraries included binary packages (like OpenOffice) and you're sure everything is included in the package. But then you loose all advantages of system-wide updates or upgrades (*).
- using a package reporitory that contains RPM specifically designed for YOUR distribution (get rpms for your openSUSE from Packman instead of some random site). Which is the method I recommand the most.
----
(*) - What I mean is that is some library, like ffmpeg has newer ability (like better capability at handling latest Microsoft WMV format), on a system that uses system dynamic libraries (like say VLC installed from Packman on a suse Linux), you immediately take advantage of it. On a system were every application has it's own set of libraries (like OS/X or GoboLinux or a package with all libs inside), you'll have to wait until next release to take advantage of it.
Same for security : when a security flaw was found in "libtiff", under Linux, you have only to download its patch and all your graphics applications are secure again. When WMF flaw was found on Windows (were mostly each application has its own copy of WMF routines), you had to check each application and patch it (at least microsoft designed a tool to simplify the process).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Ok, First turn off your flame thrower.... Now let's examine his argument rationally. It does have some merit even if he was a bit off center with his suggested solution. Like somebody else here suggested we don't need a universal package manager as much as we need a standard package format for Linux. I don't see a standard package format for Linux as being some sort of 'one true Microsoft way' any more than other computing standards like, say, the POSIX or the Unicode standards. Creating a single Linux software package standard would allow package manager developers/manufacturers to compete for creating the best product while assuring complete interoperability. Of course it would restrict competition somewhat because no individual package manager producer has control over the format but that's the price you pay for the standardization needed to eliminate the current state of affairs in Linux software package management which can best be described as a form of 'organized chaos'.
Only to idiots, are orders laws.
-- Henning von Tresckow
Sure, you can also just unzip software on a Windows box to install it but you can also un-tar software on a RPM-based linux box. So what?
It's not MSI itself: it's the standards of "put programs in certain places", "put libraries with the programs", and "give your libraries unique locations and names". If you fail to do that, you get reported errors by MSI as it attempts to overwrite another package.
RPM and apt have the same problem with conflicting packages: it's the authors of the packages, not the conflicting packing tools, that create the conflicts.
Why is that moderated "Funny"? It should be "Insightful".
./configure && make && sudo make install. Then, if ./configure fails, I'd just install whatever it was missing. All I had to do was chase dependencies; once I found them, I never had to fight with them. Occasionally, something would fail on make, and I'd have to ask a newsgroup/mailing list/web forum for help -- and the troubleshooting was generally easy.
I used to use Slackware. Then, I decided I needed to learn to use GUI tools to configure stuff, and that maybe packaging has improved, so I started using other Linuxen. I used Yoper. I used SuSE. I tried others (Debian, Redhat, Fedora, ad nauseum). These days I'm using Ubuntu (Breezy Badger).
I hate dependecy hell.
I never used to have that problem with Slackware. There were two ways to install programs.
1. pkgadd (or addpkg?) foobar.tgz -- always Just Plain Worked(tm).
2. wget sourceforge.net/packagename.tar.gz && tar xvzf packagename.tar.gz && cd packagename &&
With modern packaging systems, there's occasionally a dependency that is just automatically marked and installed, but mostly it just becomes impossible to install something -- and I fear to install from source as in option 2 above, for I may break the packaging system. A package depends on packages X, Y, and Z, each of which have ten dependencies, and most of which conflict with others, or are reported as "won't be installed" but no reason is given. If I find a way to force it, it doesn't work, or it breaks other packages, or most likely it breaks the packaging system.
The last time I used a BSD, I was extremely impressed with their packages and their "ports" system. Ports automates my option 2 above, including retrieval of dependencies. The packages system, IIRC, allows you to package up your compiled and installed ports, and labels the package with exactly the conditions under which it was packaged, before contributing it to the repository; and if the packaging program tells you that a package is available, it will Just Plain Work(tm). If it's not available, you spend two minutes waiting for ports to compile the program.
I recently was thinking of trying FreeBSD for exactly that reason.
Procrastination -- because good things come to those who wait.
Sorry but I have to step in on this, with gentoo if there is a dependency problem it will notify you as soon as you attempt to emerge a package. In most cases there is no problems with dependencies that portage cannot resolve itself, however, if you unmask a package you may end up having to unmask a bunch of other packages as well.
Yes it is possible for an emerge to break after you have been compiling for a huge amount of time, but this has nothing to do with a dependency, it has to do with either a the codebase on the application you are using being broken or the ebuild itself being broken.
This being said I personally use gentoo because I actually like having that much control over my system, I recently installed Suse 10.1 on my wifes computer and was seriously disappointed since the package updater was broken (I used suse from version 6.0 - 9.0) and I used to have a nightmare with dependencies almost everytime I installed a package. I used fedora at a company I used to work at and got to the point where I would dread having to install anything because of the dependency problems. I used debian and I was fairly impressed, however, I got fed up with having to use out of date packages. I have recently install Ubuntu on my wifes computer and overall I have been very impressed with it, so far I haven't had any dependency problems whatsoever.
Taking a step back, I am not attempting to knock anyone elses preferences, I am just expressing my experience with the various package managers, so far the most impressive for me have been portage on gentoo and apt/dpkg on ubuntu.
GeekServ Unix Consulting Services (http://www.geekserv.com)
The biggest problem with RPM for Joe Shmoe User is it is real good at reporting unsatisfied dependencies, but doesn't resolve them. I use arch linux and it has pacman, I can tell pacman to install Kdevelop, pacman knows that Kdevelop needs KDE, which needs Xorg so it grinds away and presents me with a laundry list of packages to install and asks install all 857 Mb Y or n [Y]? punch yes and everything installs, at worst it takes two tries to get everything in, then just configure Xorg and your good-to-go; my understanding is that apt-get works just as well or better.
With RPM the same installation would have to be done recursively and would probably get to 7 or 9 layers deep, a lot of us could do it but Joe Shmoe couldn't.
I've often gotten the feeling with RPM, that it also promotes distro-lock in in subtle ways, SuSE and Redhat name their libraries differently, so RPM will choke on installing a Fedora RPM on a SuSE distro. In the Debian world, all the debian based distros will install each other's apt's as I understand it, this reduces the work at each distro tremendously, if debian calls it stable, the others don't even have to check it!
Apocalypse Cancelled, Sorry, No Ticket Refunds
I have to agree with you.
I use aptitude from command line and, after working with RPM for a couple of years, I wouldn't go back to RPM even if they paid me.
Yes. Software developers should adopt /package for their software, giving their users atomic upgrades and downgrades, and easy side-by-side installations. Also see sptools and spftools for managing these types of packages.
I would suggest you to use checkinstall.
It's a wrapper for "make install" that creates a package and installs it, so that the software:
1) Gets cataloged on your system's package manager, and
2) Can be easily removed with the normal system package tools.
I made a nice script that guess all the fields of package information, like name and version (from the dir name, or from date, in case of cvs/svn/git), and pass them to checkinstall for a non-interactive one-shot install. If anyone is interested, just ask and I'll post it here.
I works very well on Slackware, and now I'm adapting it to Debian too. (I also switched from Slackware to Ubuntu, but because of hardware support. It's not that easy to configure the kernel and required software these bluetooth/dvd-burner/usb/cellphone/digicam days.)
factor 966971: 966971
My distro goes by the assumption that your the developer, if your software doesn't comply with the standards in the LSB, Linux Standards Base, it's a bug and they submit a bug-report to you and your software stays in unstable until you fix it. The rest of it is meta-data and is in their ballpark; the result is I don't deal with a lot of the problems being discussed. Other than the pain and suffering caused by the change from DevFS back to UDev in the kernel and the habitual problems with php upgrades breaking everything web related; I don't have those problems.
Apocalypse Cancelled, Sorry, No Ticket Refunds
You are resolving the same dependencies by yourself. OK, you can access the makefile or whatever and change manually the versions involved... but that might affect stability and on the other hand not everyone is able to do that. Glad to see you can
make
sudo checkinstall
And it might not cause trouble to your packaging system. The only conflict possible is files overlap with other packages (which should cause trouble as well at your Slackware and they may be resolved with the --prefix option passed to configure).
I use checkinstall in my 64bit ubuntu system when I cannot get a certain package from repos (3rd party packages in 64bit are not so widely available)
A better and more modern reference to RPM building would be this:
/
http://fedora.redhat.com/docs/drafts/rpm-guide-en
Maximum RPM is very long in the tooth these days and despite some ongoing development is broadly replaced by the RPM guide.
of course, a link to this on the rpm.org website would do no harm at all...
I don't really think so.
I've been using poldek for a past few years, and recently also on FC5. It's 10 times faster than yum to begin with (and it of course uses rpm-lib, so I don't think the ``speed'' of yum is rpm's fault and any rewrite is going to help with that). It also has this really cool interactive mode (shell-like), with package name completion.
It's a pity the package indexes supplied by Fedora don't contain file names, so you cannot search for a specific file you need. OTOH I can understand that if they did, yum would be even slower.
-- Michal
It's like your comment was written in 1999 and you just now posted it.
Why read the article when I can just make up a snap judgement?
right, because libpng2-3 really happened in 1999 instead of say, 2002-2003t ion.txt
m sg00015.html
http://people.debian.org/~mmagallo/png/png-transi
http://lists.debian.org/debian-gtk-gnome/2002/01/
i love this part in the first link though,
"First and foremost, because some development libraries depend on
libpng2-dev and others depend on libpng3-dev; since these two packages
can *not* be installed at the same time, this means you have to install
and deinstall not only libpng2-dev and libpng3-dev but also a bunch of
other -dev packages which depend on those.
"
Though it may sound familiar because the package management has barely improved since then
The war with islam is a war on the beast
The war on terror is a war for peace
With modern packaging systems, there's occasionally a dependency that is just automatically marked and installed, but mostly it just becomes impossible to install something -- and I fear to install from source as in option 2 above, for I may break the packaging system. A package depends on packages X, Y, and Z, each of which have ten dependencies, and most of which conflict with others, or are reported as "won't be installed" but no reason is given. If I find a way to force it, it doesn't work, or it breaks other packages, or most likely it breaks the packaging system.
If you are running a distro (say Fedora Core 6) against potentially inconsistent repositories (say ATRPMs), then you need a package manager that is smarter than APT or YUM. I've used Smart Package Manager to solve these complex problems for a while. It's not perfect - it may hang if you attempt to upgrade an entire release using it - but it is capable of downgrading parts of your system to match up unusual RPMs. Of course, if you stick "odd" RPMs into your system, you will have to remove them before attempting to upgrading to, say, Fedora Core 7 if you wish to retain your sanity. Package dependencies are a simple mechanism to tell you what a particular package needs. Working out all the kinks requires some pretty good graph code.
I've run RPM-based and DEB-based systems for many years. I've never hesitated to install from source if there is no RPM available for a particular package. You only break your packaging system if you overwrite the libraries under RPM/DEB control with newer ones. Almost all source packages install into /usr/local by default and will not (normally) conflict with anything you have installed from your distro. If you wish to be really paranoid or you know that there will be problems, you can always install into an entirely separate directory tree (such as /opt).I do this for 2.3.x development versions of the GIMP, for example, where the development libraries *might* conflict with the installed GIMP 2.2 ones.
Of course, you can be smarter too - you can go the next step and actually build packages for your system. Many packages have .spec files around. Similar instructions are available for DEB packages too. checkinstall can be used to tag files from a source install, making it easier to pull the files out too.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
sorry, you ubuntu-snorting asshole, but slack's pkgtool is smart enough not to step on files that exist in other packages.
Yum has indeed improved in the last couple of years. It's my understanding that it is (or was) slower than apt for two reasons:
Issue 1 has been fixed by switching to SQLite for storage backend, issue 2 has been fixed by having yum use its cache if it last updated within a certain time period (which is still less flexible than separate "update" and "upgrade" commands, but it at least works). From what I can tell, yum is continuing to be developed fairly rapidly.
It's just a simple case of wrong-tool-itis. I used RedHat and Mandrake back in their early days, and it wasn't that difficult to solve dependencies. RPM says something like "this package requires libblah.so, so I'd "ncftp redhat" and do a "dir blah* libblah*" 95% of the time that resolved it. Apt does the same thing, just with a larger database of packages. With either system, if the distribution doesn't have a build of that specific library, it's then up to you to build it yourself.
Something I haven't (easily) found though, is how to find the package name of a particular file in Debian/Ubuntu. Say you want the "foo" command, but it resides in the "blahtoolkit" package. Does apt/dpkg have an option to search it's database to find a specific file, when "apt-get install foo" doesn't work?
You take an extreme example and specify it as the norm. Thats your biggest fallacy right there.
The Macintosh does not avoid dependencies. It too has shared libraries. I don't know where you get off thinking otherwise. I've never had a problem with dependencies. You seem to have a basic problem being a user. Maybe you aren't familiar with how to use Linux - thats fine, neither does the average person. However, to mischaracterize something you totally do not understand is dumb.
I use Linux on both the desktop and the server and it works quite well. Its not even hard or time consuming.
Just so you know, your impression of software installation on Linux is out of date. On a modern distro it's a one-line command (or a single click) and the program (and all dependencies!) is installed. Thus if I want inkscape on my Kubuntu box, I type:
$ sudo aptitude install inkscape
(or pick it off the list in Adept)
Compare that to the downloading, moving file, double-click, click, click, click in windows.
I agree that software installation in Mac OS X is quite efficient (download, mount dmg, drag to applications folder), but its still slower than on Linux.
Dependency hell is gone.
yum is slow. But I can live with that. The big issue surrounding RPM is the lack of a "suggested" packages dependency class like the .deb format has. So much of the dependency hell that I've faced has to do with certain distros (ahem, Fedora Core, cough) throwing the kitchen sink in with little to no regard to the consequences thereof. However, these distros have little choice in the matter. Since rpm dependencies are an all-or-nothing affair, the distro has to bundle a lot of distantly related packages together; therefore, you're stuck installing packages for which you may have no use and then have to resort to turning things off via chkconfig to lessen memory impact and/or security footprint. As examples, many machines I install Fedora Core on will never print. However, try getting rid of cups and its gaggle of dependencies. It's not pretty. Network services such as avahi and the like are equally troublesome to get rid of and/or deactivate. And there are a multitude of others. And I'm tired of tying up network bandwidth to update packages I'll never use.
.deb. I don't see one. Choice is good, but maybe it's time to let rpm die and consider consolidation around .deb.
I'm left wondering if there is a single advantage to using rpm over
Because the maintainers make a point of only upgrading dependencies if there's a reason, it's surprisingly easy to backport packages. I don't need to upgrade a dozen supporting libraries if the updated package doesn't actually require them.
Laws do not persuade just because they threaten. --Seneca
Sometimes, it's good to monkey with the internals of a system. Sometimes you need it to Just Work.
Laws do not persuade just because they threaten. --Seneca
I'll have to look into checkinstall. Yours isn't the only reply suggesting it.
I'd definitely be interested in your script.
Now that you mention it, hardware support is probably the largest reason why I switched to Ubuntu (although my reasons stand for why I originally quit Slackware). I forgot about that. I don't mind compiling my own kernel and such, but some hardware is a real pain in the butt beyond just kernel issues.
Procrastination -- because good things come to those who wait.
how would your one line have fixed both the libc and glibc mess and the libpng2 and libpng3 mess. I used debian i know apt-get it didnt work and in finally decided to ditch linux.
The war with islam is a war on the beast
The war on terror is a war for peace
That's a lot of vitriol for somebody whose reading comprehension is obviously lacking. pato101 was talking about compiling from source, not installing with pkgtool.
How did you ever learn to use Slackware with such terrible reading comprehension ability? Did they dumb it down?
Procrastination -- because good things come to those who wait.
no i am just stating my experience with linux. Having used it since the early 90s, libpng3 was the final straw. I like your accusation that i dont know how to use linux. Calling me dumb is pretty good too. That really proves your point. I've been linux for ages and before that I used minix on a 286. I remember that the next time i'm writing a kernel module. Have you worked with any embedded platforms? have any idea what an ioctl is? dont lecture me about not being able to use linux because I like focusing on the task i am doing and not getting my OS to work.
This is exactly the kind of nerdy elitism i mentioned in my post. Unless you can figure out a tangled mess of libraries, you shouldnt be using linux.
BTW why are you posing as an AC? go home troll.
The war with islam is a war on the beast
The war on terror is a war for peace
This actually already exists and works quite well I might add:
http://labix.org/smarts p
http://www.eweek.com/article2/0,1895,1776186,00.a
It's true I tell you, feller at work's next door neighbour read it in the paper.
Since about RH 5, RPM has had a problem with locks. If your application crashes or you cancel an update or rpm install, it leaves a lock in the /var/lib/rpm dir (the __db* files). You have to remove those to get RPM to work (for example to continue your update).
My two main problems with RPM are:
1) stale locks require you to manually remove the files
2) updates often fail because of dependency lists (not so much RPM as Fedora and other repo problems)
- you have to remove the offending program (for example flightgear and one of its libs), do update, then reinstall
No RPM itself has not improved at all. It is still the same as it's always been. If you decide to download and install a single piece of software by using #rpm -ivh {application}, you will probably start hitting the downward spiral into dependency hell.
However, YUM has solved this, as well as many other package management tools, that act just like APT-GET and others. Now you can #yum install {application} and it will look for that app in the available repositories, check to see what dependencies it has, cross check with what you have installed on your machine, and then let you know what else you need. Simply say "yes" (or "no" if you want to be a jerk about it) and your app will be installed, with all dependencies in a very easy process. This becomes even easier when you throw a GUI on top of it like Yumex (rpm equivalent of Synaptic, but I still like Synaptic better), and searching for apps becomes much more manageable.
"It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson
So all those programs that used InstallShield or Nullsoft Scriptable Install System over the last six years weren't actually Windows applications? Who knew?
Laws do not persuade just because they threaten. --Seneca
I don't have experiance with deb's / apt-get etc so I can't really comment on these
However the first distributions I was using were RPM based (Mandrake)
and one of the most annoying things I found was that when writing a custom RPM spec file to setup a new package
you would have to specify which files would be installed into which directories as part of the script
I don't know if this is still the case with the current version of RPM (I'm guessing so)
But I always used to wonder why this was
and why couldn't this be automated in some way instead of bloating the the script file with something that should be automatic
After moving to gentoo even though this is a source based distro
this is exactly what it has
the ebuild scripts are very minimal, you don't have to worry about manually copying files into the system as part of the script (it basically does a dummy run using make install into a temporary directory to work out what's going where)
another advantage that could be included within RPM (this could already be a part of debian's apt etc I'm not sure)
is that the packages are grouped together under sub-headings such as sys-kernel / sys-apps and so on
Windows is hardly the system we need to model after for software installations. Everything would just be "cp lib/* /lib; cp bin/* /bin".
http://newbiedoc.sourceforge.net/tutorials/apt-get -intro/info.html.en
snippet here
3.1. Finding packages -- apt-cache search
Whether you're online or not--
How do you find the package that's got the feature you're looking for?
First, do
# apt-get update
so your package list is up-to-date, and then try something like
% apt-cache search tunnel
% apt-cache search 'php.*sql'
% apt-cache search apache.\*perl
% apt-cache search elvis\|vim
That is how you tell apt to search the packages you've downloaded,
using REGEX (regular expression, a pattern-matching 'language') -- if
your pattern uses any keystrokes that mean something to your command
shell (e.g. [|?*] ) you'll need to quote them so that apt-cache will
be able to see them, instead of having the shell expand the term to a
list of file names that mean something else entirely.
" NOTE -- apt-cache only knows about the package descriptions you've
already downloaded. To search among ALL known Debian packages just
browse to http://packages.debian.org/PACKAGESUBSTRING to see what's
available. For example: [6]http://packages.debian.org/vnc That would
get you a listing of packages that contain the term "vnc" somewhere in
the title."
and so on.
I've been reading /. for years now, but seldom did I see so many clueless posts and half-baked flame-baits packed in a single page.
/. to death.
Just for the record. (For all the clue-less posters out there.)
A. RPM is package structure.
B. RPM is a package manager.
C. RPM does not, and let me repeat myself, does not -resolve- dependencies.
D. RPM uses external tools to resolving dependencies; Namely yum, or, wait for it.... apt. (Though AFAIR apt-rpm does not handle bi-arch making it less usable for x86_64/PPC64)
E. So called dependency hell only happens when you:
- Combine different software repositories.
- Someone at RedHat/Fedora/Debian releases an incompatible update. (Happens more on Fedora; less on Debian/RHEL)
- You're using an unstable branch.
F. The introduction of Fedora (and now RHEL) extras project goes a long way to set a higher, Debian like packaging standards. (And again, this has -nothing- to do with RPM itself)
Yes, Debian has -less- dependency problems (as long as you stick to the stable tree), but this has -nothing- to do with RPM, or even yum for that matter.
At least get the facts strait before you start FUD
BTW, I spent half of last night manually recovering (using dpkg) a dead Debian Sid workstation that somehow botched the 2.6.18 upgrade (dist-upgrade)... and trust me, neither apt nor aptitude/dselect managed to solve the blunder - and somehow, you won't find me shouting like a baby that "Apt-get (or dpkg) should be rewritten from scratch).
- Gilboa
Hell no. The last thing we want to do is encourage Linux users to start running random scripts they downloaded from web sites, just because they have .package in the name.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I wasn't comparing it to non-Linux unixes, nor to non-unix-ish OSs.
Besides, the other 2 OSs beyond Linux and Windows that I've used the most (QNX and BeOS) didn't have that many packages available anyway. Both seemed to have fine graphical package managers, though I know next to nothing about the behind-the-scenes package management systems that were doing all the grunt work.
As for Solaris, yeah, it blows, or at least it did back on the version that I had to work with about four or five years ago.
What I'm saying is that, of the 3 package management systems for Linux that I've spent a lot of time using, RPM has given me several times as much trouble as the other two combined. It seems like any time someone tells me, "hey, we've got a Red Hat machine that needs some work", then at some point I'll end up needing to use RPM for something on it, and invariably it breaks. Maybe it's just my luck, but moving to dpkg distros meant that, in my leasure time use of Linux at least, package management is almost never even an issue. It Just Works (TM), and trust me, it's not because I'm not dicking around with it and installing 3rd party packages and extra repositories and such.
Yes, that's the single biggest problem I have with RPM.
Sure, you can layer Yum or APT on top of RPM and have a workable UI, but that doesn't solve the fundamental problem, which is that RPM still regularly corrupts its own database, sometimes irreperably. The most recent occurrence for me was a couple of months ago on a SuSE 10.1 system; I never did find out what triggered it, but I wiped and reinstalled and it's been fine since, so the hardware doesn't seem to be the problem.
I've resorted to taking a back up of the entire /var/lib/rpm directory before every major update. I shouldn't have to do that. I have never, never had APT or dpkg hang or corrupt their data irreperably.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
> RPM will choke on installing a Fedora RPM on a SuSE distro
NOW THIS IS A GOOD THING TO BRING OUT.
RPM could improve on compatibility errors from using a foreign distro's RPM:
EG: Error: "Incompatible binary format of this RPM. Unable to read this RPM.".
OR: Error: "You are attempting to run an RPM for SuSe on Fedora...."
Or: Give reasons why this foreign RPM is incompatible on this version of Fedora.
One of the features of dependency checking I'd like to see is:
RPM knows this distro was installed with CD, and prompts for the given CD, as appropriate.
Drawback: Updated versions of dependencies will be ignored.
Sequitor: YUM already does this thru the use of it's repositories.
RPM should have a way to call YUM from the command-line for dependency issues.
This would give RPM a seemless interface to YUM to resolve all dependencies for a given RPM.
EG: rpm -i -y[i,r] something-1.1.1.rpm
The 'y' invokes YUM and either (r)eports the dependencies or (i)nstalls the dependencies.
Perhaps RPM should scrap YUM for dependency resolution in lew of APT.
This would give RPM and DPKG a common "dependency resolution" wrapper, that fits closer to an LSB-centric approach.
EG: Why have two wrappers for RPM and DPKG, rather than one?
In either case of which dependency wrapper RPM uses, a command line interface switch for RPM should be available to call or query that dependency resolution wrapper. This would help in the confusion folks have demonstrated in their responses (above), regarding package managers like RPM and DPKG and dependency resolution wrappers like YUM and APT.
This would also demonstrate how RPM relates to that wrapper (Yes, I know the YUM actually uses RPM, but it would be cool, if I could call YUM from RPM cmd).
"First and foremost, because some development libraries depend on
libpng2-dev and others depend on libpng3-dev; since these two packages
can *not* be installed at the same time, this means you have to install
and deinstall not only libpng2-dev and libpng3-dev but also a bunch of
other -dev packages which depend on those.
" You realise that libpng2-dev and libpng3-dev are just the development packages, don't you? They're only required when you want to compile something that needs the header files included in the packages. The binary packages of libpng2 and libpng3 (at least in Woody and Sarge) use different files, so there appears to be no reason why they cannot be installed on the same system.
fedora and debian need to come up with a unified package database format (xml) that supports the superset of popular package formats.
That Fedora moves very fast, MUCH faster than Debian.
If the last time you tried using Redhat was 5 years ago then you really don't know what's going on with the distro.
5 years may be one release cycle for Debian but for Redhat/Fedora that is a ridiculously long time.
Even using Fedora 6 months ago may not show you the latest improvements.
Exactly the opposite of my experience. Since I am quite comfortable with RPM, and know exactly what it can do and how it does it, that "sea of terse explanation" is exactly what I want to see if I do a --help. By comparison, every time I do the same switch on debian I am quickly frustrated. It just won't tell me how to do what I need to do!
I don't think it's "messy" nor do I think it needs to be replaced. It does exactly what I use it for, rapidly, reliably, and well. If you're trying to use a claw-hammer like a wrench, you'll have problems, and that's why I have problems with dpkg and you have problems with RPM. It's the user, not the tool.
Learning how to use it right might work better than whinging. Of course I complain about
They will probably make RPM "better" the same way. I'll keep using the old versions... you are welcome to your
But seriously...
Bloat is one reason for not wanting apps to store things in their own folders. Not just disk space, but RAM usage. And yes, people are still running Linux on a 4 gig drive and installing multiple applications -- for that matter, if you are using Linux, you're almost certainly using "multiple applications" in the form of multiple daemons running at boot.
There's also download time. Suppose a dependency is updated -- you don't have to re-download every single app that uses zlib to get the zlib update. And if you already have a bunch of libraries, downloading a new app takes less time. The SVN snapshot of VLC 0.8.6 for i386 is a little over a megabyte. Compare that to the 0.8.6 download for Macs -- the Universal Binary is 22.7 megs. Now, it may well add up to just as much when you count the libraries, but then, it might not, especially if you already have, say, mplayer or totem installed. And not all of the libraries are updated every VLC update, which means I get to download about a megabyte, and you download 22.7 megs.
Speaking of updating, it also means that you can get updates -- including security patches -- to just a library, and not have to patch everything that uses that library. A very simple example: Suppose OpenSSL has a critical security flaw. My package manager will automatically install a new version of OpenSSL, and like magic, my SSH daemon, my web server, my IMAP server, anything on the box that uses SSL will have that flaw fixed.
And it all happens automatically. On Windows, you have Microsoft Update, which updates Windows and some Microsoft apps, like Windows Media Player, Internet Exploder, and Office. On OS X, you have Software Update, which updates OS X, iTunes, QuickTime, and some other Apple apps. On Linux, you have a package manager, which updates every single program that's installed on your computer. I'd estimate that over 50% of the apps I use every day on my Mac are third-party apps, and maybe 3 or 4 of them check for updates automatically -- the rest, I have to check myself. To do the equivalent of an "apt-get update && apt-get dist-upgrade" (or equivalent GUI) on a Windows or Mac machine would probably take a solid couple of hours of hunting down the download sites of every single program I have, opening the program, checking my version of the program against the latest download available... On Ubuntu, I just wait for there to be an icon in the system tray telling me I need to update.
Dependencies are not an issue on Linux. They just aren't. Every now and then you have a weird issue, but generally it's fixed by the distribution the same day. We have coherent distributions, and even most third-party stuff Just Works out of the box. We have a way of actually maintaining separate versions of a shared library, so even in the event that App1 depends on LibFoo verison 1, and App2 depends on LibFoo version 2, we can simply have both versions of LibFoo installed -- automatically, as dependencies, by the package manager. Eventually, App1 will be updated to support LibFoov2, and when that happens, LibFoov1 will automatically be uninstalled.
And you're kidding yourself if you think that dependency problems don't exist on other OSes -- you'd be amazed at the problems getting stuff to work on different versions of MacOS. Dependency problems with the OS itself!
As for portability, I'm not sure what you mean here. If I write an app that depends on, say, SDL, but I don't ship it with SDL, it can actually be more portable, because different Linux distros might have different versions of SDL. It's true, they might break compatibility with me, but they generally don't, and they might also workaround some bug that I'd certainly have hit if I insisted on using my own SDL.
There's also security. How do you install a Windows program from the Internet? Browse to a website and download an EXE? Do you have any clue how ridiculously insecure that is?
When I install a Linux program, I generally install it through the package man
Don't thank God, thank a doctor!
I started linux with fedora, and then it was formatted in a weeks time with windoze on it (my uncle, a windoze sys admin, thought I should use it, and not linux), and from what I saw of it, fedora was Ok, and the packet manager is kinda cool.
The problem with it is that it isn't universal, and the same problem exsists with apt -get install, which I would love to be put into slackware (which i was dragged into - fist full time distro+slackware= PAIN+steep_learning_curve), and am even thinking of getting Debiean purely for the apt command... it would make life a LOT easyer.
OMFG if I have to ever use a system with rpm as its standard method of packaging I will vomit.
.deb packages.
.deb to the masses.
Debian has changed my life in ways I could have never imagined without
I mean who the fuck uses cds to install anymore? What a waste of plastic.
Since USB install is so easy now:
http://www.debian-administration.org/articles/446
or even encrypted:
http://www.debian-administration.org/articles/179
Apt-get is the best technology since the internet was created.
Nothing can or will ever compare to the amazing ability of apt-get to install any one of 18000 programs and have you using it right away. And thank god for ubuntu bringing
All we need now is an open source Turbo Tax and the masses of bill gates slaves will be FREE from his reign of terror.
The best system I've had th pleasure to use was Ximian's Red Carpet. Their UI was easy to use and it worked well and geeks like me could stick to the command-line tool, rug, which was more coherent than any other packaging tool I've used (including apt, yum, etc). I wish that the developers of other packaging systems would make an effort to work as well and to be as easy to use as Ximian's system was.
I wonder if RedHat couldn't work with the Debian folks at making a real merge of the packaging systems. It'd be wonderful to do away with having to know multiple systems. The majority of distros are based on either Debian or RedHat so really those are the two most important systems - if they could find peace then everyone else would eventually fall into line. Tool developers could develop a single set of tools for dealing with packages without a lot of overlap.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
It's like your trying to speak english, but the internet is making you use math symbols and things to link words.
Yum is better anyway.
Why bother? dpkg/deb is maintained and does everything that rpm does.
/etc
Bzzzzt WRONG!!!
I *prefer* Debian over any RPM based distro I have ever used but to say that dpkg/deb does *everything* that rpm does is simply false.
dpkg/deb fails to do at least one very important thing that rpm does.
rpm maintains a database of, among other things, filesystem ownerships and permissions as well as symlinks.
dpkg/deb manages filesystem ownerships, permissions and symlinks by running commands in the maintainer scripts. It does not maintain *any* database of these objects or properties. I'll give a real-life example...
I once had the misfortune to lose all of the symlinks under
The system was rpm based so it was a relatively simple matter to query the rpm database, extract the info on the symlinks which are created by the package installations and turn this into a script to recreate them.
Had this been a deb based system I would have had to reinstall the packages which may not have been practical; more likely I would have had to troll through all the maintainer scripts thinking my way through their logic to find where they created symlinks. And in many cases they are not simple linear shell scripts!
Once dpkg/deb starts to maintain this kind of data on package installations, *then* you might say that it does everything that rpm does. Not before.
In the free world the media isn't government run; the government is media run.
wouldn't making something with auto-conf and then auto-make work?
So Jeff Johnson has left Red Hat, eh? Anybody know what happened?
The good-news part of this is that we won't have him blocking improvements to RPM any more.
In times of universal deceit, telling the truth gets you modded -1 Troll
That seems downright retarded of you. You had a Debian bug, and rather than try one of the hundreds of other distros out there, you just go straight to a Mac? I haven't run into any problems like this on Ubuntu...
True, it doesn't. It has package managers, and there is a technical reason for that.
apt-get. Or one of the many GUI frontends, which end up being far quicker and easier than any Windows or Mac install I've ever seen.
As mentioned elsewhere, these are the devel files. If you're compiling software on your own, then yes, you need to know how to deal with these. Worst case, you can head over to libpng.org and download the version needed for whatever you're compiling.
And yes, compiling custom software will require you to deal with strange stuff like how to force an app to use specific header files, even if they aren't where the app expects them.
Hmm. Could you remember which apps these were, which relied on development libraries?
More importantly, did you even try to get support before you threw your hands up and left?
Not as much as software maintenance on OS X. Consider: I can do "apt-get update && apt-get dist-upgrade", or I can follow the GUI prompts when Ubuntu automatically finds updates for me. You have to spend a couple hours looking through every single app you have installed, comparing the version you have with the version online.
Great, thanks, now every single app will take 10 times as long to download and use 10 times as much disk space and RAM. We'd never have gotten out of the "stone ages" of an efficient OS if it wasn't for you! Thanks for thinking of something so new and non-obvious that every Linux developer has already thought of it (and rejected it) before you!
I am not making this up, by the way. VLC's Universal Binary for OS X is a solid 22.7 megs. The VLC deb file (Ubuntu, i386) is 1.1 megs, because the rest of it is in shared libraries -- most of which I'd already have.
Now, I realize a mere 21.6 megs of wasted bandwidth and disk space isn't worth crying over, but why would you waste it when you don't have to?
And anyway, what's stopping you? Roll your own distro the way you want it and see how far you get.
Don't have the time? Get someone else to. Organize. Maybe try a post to Slashdot that isn't immediately (and rightly) modded Flamebait.
Don't thank God, thank a doctor!
One big difference is, last I checked, rpms had size limitations that debs don't. So, I just like the deb format better.
/usr/bin/mozilla. A deb would depend on "web browser" or something, which could be satisfied by Mozilla, Firefox, Konqueror, lynx, links, w3m, Opera, even Amaya. Of course, there would be a default to install (probably Firefox or Konqueror), but if you already had a different browser installed, that would work, too.
But, we're really talking about apt vs yum. From what I was reading, the way yum/rpm handles dependencies is through files. That is, a package lists the files that it depends on, and the package manager finds out what packages provide those files.
On the other hand, apt, like most sane package managers (Gentoo's Emerge is another one), depends on other packages. And, there are all kinds of things you can do with them, including virtual packages, allowing for multiple alternate dependencies. For example, an RPM file that needs a web browser installed -- say, to display documentation -- might depend on
This also means that a package can depend on a specific version of another package, or have a minimum version required.
So, that's a pretty big fundamental difference, and it'd take a lot of thinking and probably a lot of deep, incompatible changes to make RPM come anywhere close.
Besides, apt is more popular at the moment, and it's used by Ubuntu, which is more popular at the moment. That means there are tons of really nice frontends for it, everyone's using it, everyone knows best practices for it, and so on. And, since it's open source, that also means everyone's developing it when it needs to be developed -- all kinds of people that might be interested in helping with RPM are already using Ubuntu and Apt, so they'd rather just add the feature to Apt.
I cannot think of a single thing that rpm/yum does that apt/dpkg doesn't. I've already listed something that apt/dpkg does well, that rpm/yum might possibly be able to do with a really ugly hack.
Think of it this way: FreeDOS could be improved. Linux could be improved as well. Which would you rather start with to make a modern OS?
Don't thank God, thank a doctor!
The thing is, utilizing yum may not be the "most obvious way" to us old-timers that cut our teeth on RPM.
You can be an atheist and still not want to succumb to some weird cross-over sheep disease -- AC
It's not universal, but neither is MSI. MSI works under Microsoft "distributions". Deb files work under apt/dpkg distros.
Don't thank God, thank a doctor!
No, the RPM Package Manager. The acronym was made recursive when they realized it is used by more than just Red Hat.
You are misunderstanding just a bit. The package manager isn't the problem, it's the distro. Specifically, dependencies.
/usr/bin/mozilla, not "web browser package".
/etc/init.d/apache -- but it might have different ways of running it, like "reload" vs "restart". On newer Ubuntu systems, it may be managed more directly by upstart. On a system by DJB, it might be handled by svscan. On Windows, it'd be a service.
Consider: RPM doesn't depend on packages, it depends on files. That is, an RPM file will depend on
Most other systems work more sanely -- a package that needs a web browser can depend on "web browser" or even "Netscape-compatible browser", and those, in turn, could have lists of alternate packages that could fill that role. But even here, you have problems: Suppose a package depends on Firefox. Do we install the Ubuntu Firefox, the Debian Firefox, the RedHat Firefox, or the Gentoo Firefox? All of them could be slightly different, and have slightly different dependencies.
I know you're saying "they should be the same" -- but consider Apache. On OS X, it'd be handled by launchd. On most systems, it'd be an init script --
So, after we upgrade Apache, we want to automatically restart it. How does our universal package manager know what to do? Each package will know what to do -- on the distro it was designed for.
And that's assuming coherent packages. For instance, on Gentoo, support for various things is controlled via USE flags -- for instance, mod_ssl might be part of the Apache package, assuming you have the "crypt" USE flag enabled. On Ubuntu, it'd probably be a separate package that depends on Apache. And you see this kind of thing all the time -- how do we split things into packages? What if I have a package that depends on xmms-plugins, but that's included in xmms?
Now, if what you're talking about is a way to install packages from another system, we can sort of do that. Gentoo does it a lot -- it'll download an RPM or a DEB, unpack it into its files, and do some custom stuff to them. But you have to do that manually for every package -- figure out what it depends on -- which is why most other distros will just repackage it for you, unless you're going to end up doing it yourself manually.
Because, you see, it's not the package type or the file format. What you're asking is roughly equivalent to asking Slashdot to combine with Wikipedia.
Don't thank God, thank a doctor!
the libpng link was just to show that the transition from libpng2-libpng3 was not in 1999 like someone claimed. I've used all the major distros other than gentoo and none just work.
>Not as much as software maintenance on OS X. Consider: I can do "apt-get update && apt-get dist-upgrade", or I can follow the GUI prompts when Ubuntu automatically >finds updates for me. You have to spend a couple hours looking through every single app you have installed, comparing the version you have with the version online.
Where on a Mac do you have to look through every app? seems you have never used software update or mac update.
>I am not making this up, by the way. VLC's Universal Binary for OS X is a solid 22.7 megs. The VLC deb file (Ubuntu, i386) is 1.1 megs, because the rest of it is in shared >libraries -- most of which I'd already have.
Excellent comparison, one day you may want to install a new app thats not in ubuntu's repository that needs a different version of wxWindows than the one you have. You upgrade it and may break VLC.
I install the other app and it works independently of VLC. How much does it cost? 20 mb. Since you used an example of a program that was not written in cocoa or carbon, let me show you my strawman.
I have photoshop which runs natively with the existing libraries in OSX. I dont need to install every obscure package. For you to use photoshop you need to install wine. Fine.
Then i use dreamweaver, great native version. You want to use dreamweaver, same thing, no dependency hell. However, you might need a separate version or configuration of wine. If it is a different version, thats gonna be a bitch isnt it?
Also, nearly all OSX software use built in functions provided by the OS and are written in either carbon or cocoa. This could easily be replicated with one version of gnome and one version of kde on a version of a distro.
Roll my own distro? why bother duplicating OSX when it already does everything I need it to do. Thats my whole point actually, in linux you need to focus on getting you OS work right rather than doing the task you set out to do. Its a time sink.
The war with islam is a war on the beast
The war on terror is a war for peace
Trying to resolve dependencies manually, well it can certainly be done (been there), but really. I honestly thought that most people involved would have heard about dependecy solving package managers by now. Those who haven't, rejoice, they're here!
#!/bin/bash
..; echo $PWD)`"
/etc/slackware-version; then /etc/debian_version; then
date=`date +%Y%m%d`
name="`basename $PWD`"
[ "$name" == "src" ] && name="`basename $(cd
if test -d 'CVS'; then
args="--pkgversion=cvs.$date"
elif test -d '.svn'; then
args="--pkgversion=svn.$date"
elif test -d '.git'; then
args="--pkgversion=git.$date"
else
name="`echo "$name" | cut -d - -f 1`"
fi
if test -f SConstruct -o -f Sconstruct -o -f sconstruct; then
cmd="scons install"
else
cmd="make install"
fi
if test -e
t=slackware
elif test -e
t=debian
elif true #TODO: proper test for redhat
t=rpm
fi
cmd="sudo checkinstall --type=$t --nodoc --pkgname=\"$name\" $args $cmd"
echo "$cmd"
read -p "proceed ([y]/n)? " answer
test "$answer" == "y" -o "$answer" == "" || return
$cmd
factor 966971: 966971
I did use Software Update -- only works for Apple products, certainly not for (say) VLC. A quick glance at Mac Update shows a huge list of software downloads, but certainly no update software to automatically check -- so in that case, I still have to go through every app and check it against the macupdate version.
Oh wait... there it is, an app to check your actual installed software against MacUpdate... That's actually pretty fucking buried, and it costs money.
Not too likely. Most apps provide an Ubuntu version, at least -- so even if it's not in the main repository, they'll have their own repository or at least a .deb file.
I'm guessing that by "different", you mean "newer".
You're assuming the same behavior as your libpng-dev example. VLC, on Ubuntu, doesn't need dev libraries, which means that you can have multiple versions of that library, if you really need to.
Assuming it's something not in the Ubuntu repository, it may make sense for people to package it that way. It seems much more likely that it'd simply depend on the library that's in the repository -- which, by the way, won't be updated by Ubuntu unless it already works with VLC.
And if your way was the standard, it would be absolute hell on older machines. When you have 64 megs of RAM, you start looking at that 20 megs a bit differently -- especially considering it's a single app. VLC will take 20 megs of RAM anyway, but now VLC + some other app = 40 megs.
I haven't even mentioned cache coherency yet. The cache is 1 meg at most, so the more redundant crap you have, the slower your apps run, even if you're swimming in RAM.
And what does it buy you? Less chance for someone to screw up, in one particular way. Dependencies allow less chance to screw up in several other ways -- for instance, you may upgrade wxWindows and find it fixes what you thought was a bug in VLC. Of course, it might introduce a bug, but you'd have gotten that when you upgraded VLC anyway.
Again, that distinction between system libraries and other libraries. Suppose Apple patches Cocoa or Carbon in such a way that new apps need the new version, and old apps need the old version? Is there even a provision for multiple versions of these libraries?
And this has happened. Just about every OS X upgrade breaks apps from a version or two ago, and introduces a ton of new stuff that means new apps won't work with a version or two ago of OS X. And somehow, users seem to cope.
All of this is theoretical, anyway. You have one example of a development library having some resolvable issue. Boo fuckin' hoo. Do you have any real examples, that actually impact users?
Because I haven't seen or heard anything about dependency hell for years, on Gentoo or Ubuntu.
Actually, I'd use the Gimp, but alright...
Oh, and it also runs in Windows. What makes you think Photoshop doesn't have a cross-platform library of their own? The only difference with the VLC example is, wxWindows is public and can be shared between apps, whereas Photoshop doesn't give us their cr
Don't thank God, thank a doctor!
you know who wears a brown hat? Dirty Old Ike. But I'm guessing you already knew that...
Do you even lift?
These aren't the 'roids you're looking for.
Hey gang, using PCLinuxOS via Synaptic pretty much gets rid of the dependency hell - synaptic takes care of the dependency issues when installing. Uninstalling is another issue - just like Windows programs typically do, uninstalling doesn't leave you with the same footprint that was there before installing (i.e. some of the packages stay on the system that aren't needed). Anyhow, I've long forgotten about the RPM dependency hell and leave it to synaptic to figure it out and Redhat would be wise to follow the same format and improve synaptic for install/uninstall functionality while improving RPM.
Maybe you need:
:)
$ apt-cache search keyword
$ apt-file find filename
Those will show you the package you need. No need to switch distros and do everything by hand.
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
GeekServ Unix Consulting Services (http://www.geekserv.com)
At the end of the day, Linux is just a kernel.
The Debian platform has such a universal packaging system (dpkg) and a set of standards that developers use to correctly integrate their software into the Debian System.
Other distributions (one would hope) have their own standards. The problem is that everyone wants "Linux" to be a platform when it is only a component. And everyone wants "Linux" to be a platform/operating system when really the platforms are Debian, Fedora, etc.
Now, if only they would fix the embarrassing bug in RPM. :)
Since dpkg maintainer scripts are idempotent, reinstalling all the packages should have been a very straightforward way to get everything back.
:)
But the easiest way to get everything back would have been to restore your backups...
Since dpkg maintainer scripts are idempotent, reinstalling all the packages should have been a very straightforward way to get everything back.
:)
;)
Are *supposed* to be idempotent.
But the easiest way to get everything back would have been to restore your backups...
Smartarse
Still, from the perspective of being able to validate the installed state of packages, rpm is miles ahead of deb.
In the free world the media isn't government run; the government is media run.