Fedora Project to Help Revitalize RPM 334
-=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."
First improve the UI (Score:4, Insightful)
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
You Have It All Wrong (Score:5, Insightful)
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.)
Re:You Have It All Wrong (Score:2)
Repository management works well in pkgsrc with pkg_add, pkg_del, pkg_info, etc. There is no need to add an apt or yum lookalike over the top, and the interface is simple and intuitive.
The situation with yum seems to be that rpm is in the THB (too hard basket) and they are writing a wrapper to hide the problem.
Re:You Have It All Wrong (Score:4, Informative)
Yum and others handles repositories and dependency solving.
If you want something user friendly ... (Score:2, Insightful)
"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.
Re:If you want something user friendly ... (Score:4, Interesting)
Re:You Have It All Wrong (Score:2)
It wasn't all that long ago that this wasn't possible in RedHat. IIRC, everything before Fedora Core, "rpm -ivh <package>" was exactly what you did. If it had dependencies, it would tell you, but actually solving them was your problem. This was the exact reason I moved to Mandrake (as it was then), which had already improved matters substantially with a program called urpmi.
Re:You Have It All Wrong (Score:5, Interesting)
If you look at the output from 'dpkg --help' and compare it to RPM's, RPM provies a much longer list of options, the vast majority of which no one ever uses, burying the commonly-used functionality in a sea of terse explanation.
The RPM tool needs to be replaced - possibly with another version of the tool, but removing all the extra cruft from the way it's used. It makes no sense to say 'Well, of course it's messy because you shouldn't be using it'. If the tool exists, it should be usable.
Even with the APT frontend picking up the slack, Debian has managed to keep dpkg easily usable and keep the help options straightforward, to the point where I rarely have to dig for what I need to do. When I go to work and have to work with the package management tools on Fedora (yum on our workstations) or RHEL (RPM on our servers), I hear nothing but complaints about usability, speed, and reliability from coworkers.
RPM needs an overhaul, badly, but I doubt it'll get the one it needs.
I have a... (Score:5, Funny)
Re:I have a... (Score:2)
Re:I have a... (Score:4, Funny)
Re:I have a... (Score:4, Funny)
Re:I have a... (Score:2)
Re:I have a... (Score:2)
Re:I have a... (Score:2)
rpm is both the file format and *a* tool to work with them, just like you can use apt to install a single, downloaded
Another major RPM distro is Suse. In their world, YAST compares to apt.
Code cleanup... (Score:5, Funny)
Easy job, this took care of it.... :
rm -rf
Has RPM improved at all? (Score:4, Interesting)
Re:Has RPM improved at all? (Score:3, Insightful)
The people who think this is easy to solve are the people who are happy to update 15 packages to fix one program that has a dependency it doesn't even really need on an upgraded version of another, trivial package, and then are surprised when they destabilize their whole OS because the other 1500 packages have never been tested with those new 15.
Re:Has RPM improved at all? (Score:2)
Re:Obligatory.... (Score:2)
My experience with RPM hell is exactly what made compiling everything in Gentoo seem like a reasonable alternative. It was that bad.
Now I'm on Ubuntu, and much happier than I was even with Gentoo and Debian, but I'd still take either of those over Red Hat. *shudder* I like to be excited when installing a new pacakge, not terrified!
misread (Score:4, Funny)
Anti-FUD Post (Score:5, Insightful)
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
Come again on that one? (Score:5, Informative)
That would be the Redhat Package Manager, right?
Re:Come again on that one? (Score:2)
Re:Come again on that one? (Score:2)
Pro-FUD Post (Score:2)
Re:Pro-FUD Post (Score:2)
*Package-format* to take care of ? (Score:5, Informative)
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 [wikipedia.org]).
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 [slashdot.org] 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).
Re:Pro-FUD Post (Score:2)
Re:Pro-FUD Post (Score:2)
RPM is used by RedHat, Suse/Novell, Mandriva and Centos, some of the most popular distributions. It's not really known how large a marketshare the popular distros have, but I think it's fair to say that RPM is roughly comparably in popularity to dpkg.
Re:Anti-FUD Post (Score:2)
What would you call it, then?
Very good, Captain Obvious (Score:2)
In other such news, gcc is free software, the Amiga is dead, and littering is bad.
Re:Anti-FUD Post (Score:2)
Re:Anti-FUD Post (Score:2)
Is this one of those recursive initialisms like GNU?
RPM's Painfully Mutable
RPM's Pretty Mindwarping
RPM Perpetually Mangles
Good. (Score:4, Interesting)
Re:Good. (Score:2)
Re:Good. (Score:2)
So? I mean, unless you've got crazy-small amounts of ram. It's not like it slows it down any, as far as I can tell.
Re:Good. (Score:2)
But why then apt-get works faster than yum? Earlier versions of apt were written I think in Perl (yum is written in Python) but still yum (implemented after apt) seemed like step in wrong direction.
Also, yum is even slower than aptitude and aptitude does one hell of checks and tests - as well as pile of algorithms to solve dependency problems. (Never living with four concurrent repositories was easier in my life.)
That really surprised me when I found out that Debian's apt doesn't use database for its repository - and still worked faster than yum. And the mundane rebuilding of database one has to do for rpm (stuck with us from times of rpm database upgrade) is just not needed with apt.
P.S. Raw dpkg is slower than rpm precisely because rpm uses fast database, while dpkg has to update huge text file.
Re:Good. (Score:4, Informative)
You can roughly emulate package dependency using specific files (or symlinks) within packages which are just there to deal with dependencies, but it's messy compared to a system designed properly from the outset.
Re:Good. (Score:4, Insightful)
Bollocks. You might claim (although I'd probably disagree) that apt under Debian has an easier time of resolving dependencies than does yum under Red Hat. But apt under Fedora vs yum under Fedora? Probably fairly equal, I'd say. I'm also slightly bemused by your implication that RPMs are dependent on files, rather than on other packages. Where on earth did you get that one from?
Re:Good. (Score:2)
As for RPM itself, there is nothing wrong with it. Feature-wise it probably better then dpkg, but the big difference is the _repositories_. Yes, Debian and therefore Ubuntu have very well maintained repositories. I did not have any dependency hell in Ubuntu (yet!?), but I remember having it with SuSE, Fedora, Mandrake and Red Hat. So I am not blaming RPM, but rather Redhat and SuSE.
Re:Good. (Score:2)
The first time I tried Ubuntu (OK, honestly, the first time I tried the one from 2 releases ago, 'cuz the 3rd release back sucked) it was like someone had installed Gentoo, then spent a few days configuring 99.9% of everything exactly the way that I wanted it, including all the shit that I never had the time/patience to figure out how to do on my own.
Wonderful. Perfection. It'll take one hell of a distro (or one hell of a screwup on Ubuntu's part) to get me away from it.
Re:Good. (Score:2)
Fedora Project to Help Revitalize RPM (Score:5, Funny)
[dodging tomatoes]
While they're at it (Score:2, Insightful)
Re:While they're at it (Score:2)
Forgive me, but... (Score:2, Interesting)
We don't need an rpm update (Score:2)
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?
Re:We don't need an rpm update (Score:2)
Any good distro differentiates itself through offering a quality user experience. Look at the massively popular Ubuntu and the rising of Xandros. Both are Debian based distributions but favoured for different reasons. They are unique yet on an architectural level they have a common heritage. Fedora should raise the bar and choose the best tools for the job. I can't count the number of times I've heard someone say they tried Fedora but gave up because of package dependency / conflict resolution problems.
Just switch to apt (Score:4, Interesting)
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.
What is a Package Manager for? (Score:2)
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.
Re:What is a Package Manager for? (Score:2)
Re:What is a Package Manager for? (Score:2)
For example, in RPM distros I like to clean up packages that I do not use. It's pretty easy because I can easily generate a query with summary information telling what every package does. In Windows this is quite difficult. The Add/Remove programs has little information and doesn't include all packages. It's difficult to determine (or at least I don't know how) what package owns which files. How do I tell if a file has changed in a package? How do I tell the interdepencies with the packages? How do I create a list of installed packages so that I can document the system as part of compliance efforts? Even relatively simple tasks such as maintaining a local update repository seems more difficult with the current Windows Add/Remove and installation tools.
Many of these deficiencies are remedied with third-party applications for system management and package building, but it's just another app to manage (and pay for) for me and my company. Again, I'm just a Windows user and not an admin and may just be ignorant of how to do these tasks on Windows.
Re:What is a Package Manager for? (Score:3, Interesting)
There are reasons other than bloat for separating out dependencies. For instance, say a vulnerability was reported in zlib. If every application had their own implementation of zlib, then one would have to replace zlib for every application. A shared library doesn't have this problem; it can be upgraded without problems so long as it remains backward compatible. Compartmentalising functionality is common practise in the open source world.
However, there are various file distribution systems available for Linux that include dependency files with the application. Klik [atekon.de], for instance, wraps up applications in a self-contained compressed filesystem. However, the problem with modern Linux distributions is not so much dependencies, but a lack of a common method of installing software.
We don't need RPM, we need something else! (Score:2, Interesting)
Re:We don't need RPM, we need something else! (Score:2)
Quitter! http://klik.atekon.de/ [atekon.de]
I have a suggestion (Score:4, Interesting)
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.
Re:I have a suggestion (Score:2)
If you could have bundle packages, you could install just the application and request the devel stuff if you wanted. Better yet, if you were packaging software for sale, you could include all the dependency packages in your application package and install whatever bits were missing.
I'd also add that the REAL reason RPM is not as convenient as dpkg has absolutely nothing to do with RPM itself. The big deal is that each RPM-based distribution uses its own naming conventions for packages and the dpkg-based distributions adhere to a more coherent convention. The problem is that RPM notes dependencies based on package names (and virtual package names), so if one system requires gcc4, but you have gcc-4 installed, despiet being the same thing the system sees them as different. On Mandrake you might need a 'libwidget' package whereas the library might be included in the RedHat 'widget' package.
The insanity is a result of naming conventions.
I'd also add that adding a repository ought to be as simple as clicking on a link on a web page. This is not an RPM/dpkg issue, it's one for Yast/Aptitude/etc.
I like it (Score:2)
Re:wow (Score:2, Insightful)
They're not trying to "bring it back", but to "make it better".
Btw. I'm writing this on a FC6 box, no problems here
Re:wow (Score:2)
RPM for all it's frustrations is just dandy with an apt or yum frontend. The other point is that most people running RH are running servers. We're geeks anyway, don't usually go outside of the core software set, and use Redhat because of the Q&A testing.
RPM kinda sucks for resolving dependencies, assuming you don't know what they are.
Aside from Debian, RHE3/4 is the only game going in my book. And I can't tell the president of a company that Debian is supported by a company they have heard of...
I've got 36 internet facing servers I manage. Next year it could be as high as 200. If nothing else RPM presents a known quantity which represents a certain level of security.
Re:wow (Score:2)
As soon as you would try to customize installation you would find that it is not as trivial as it might be.
If you do not customize your distro - then it's fine. If you customize rarely - yum would still do fine job.
But if you have too have some latest version (e.g. I need to have latest gcc installed, so that I can test the compiler) rpm/yum become major pain in the ass. E.g. new version needs new library or new version of library and the library has it's own dependencies. Aptitude now handles everything for me nicely - yum in past was barely capable of conflicting packages handling of several repositories. Not to mention that it did that very very slowly.
And do not forget that LD_KERNEL=2.2.5 - or rpm would hang yum. You would have to kill -9 it and then clean/rebuild repository. Or it doesn't hang anymore? Or RedHat set the variable system-wide? Or RedHat finally got down to earth to fix their beloved futexes? [/sarcams]
Re:wow (Score:3, Informative)
Fortunately, db4 seems to be dead: it's been replaced in such lightweight applications by SQLite, there are a lot more and faster mirrors available, and the repository information is stored more effiently, or at least handles a lot faster with faster modern machines. So it's overall gotten a lot better: take a look at the versions of the past year or two to see how good it's gotten.
Re:I've got something to say! (Score:5, Interesting)
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.
Re:I've got something to say! (Score:5, Informative)
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.
Re:I've got something to say! (Score:4, Interesting)
Personally, I have always used apt-get instead of aptitude.
Re:I've got something to say! (Score:2, Funny)
Re:I've got something to say! (Score:2, Informative)
First of all open a terminal and edit
near the end of the file uncomment so it looks like this:
Code:
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
alias h=history
alias untgz="tar -xvfz"
alias untbz2="tar -xvfj"
Re:I've got something to say! (Score:3, Interesting)
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.
Re:I've got something to say! (Score:4, Interesting)
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.
Re:I've got something to say! (Score:3)
I'm left wondering if there is a single advantage to using rpm over
Re:I've got something to say! (Score:2)
Re:I've got something to say! (Score:2)
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.
Re:I've got something to say! (Score:5, Informative)
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
Re:I've got something to say! (Score:2, Insightful)
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...
Re:I've got something to say! (Score:5, Informative)
Or do I completely mis-understand how things work under linux ?
-Jar.
Re:I've got something to say! (Score:2, Interesting)
Re:I've got something to say! (Score:2)
Re:I've got something to say! (Score:2, Funny)
I should look for Y-movies
Re:I've got something to say! (Score:2)
Re:I've got something to say! (Score:2)
Re:I've got something to say! (Score:3, Interesting)
*Throws down gauntlet*
-Jar.
Re:I've got something to say! (Score:4, Interesting)
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.
Re:I've got something to say! (Score:2)
Re:I've got something to say! (Score:2)
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
Re:I've got something to say! (Score:3, Informative)
Re:I've got something to say! (Score:4, Interesting)
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.
Re:I've got something to say! (Score:3, Interesting)
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.
Re:I've got something to say! (Score:2, Informative)
# 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:
Re:I've got something to say! (Score:5, Funny)
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.
Re:I've got something to say! (Score:5, Funny)
Re:I've got something to say! (Score:3, Interesting)
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.
Re:I've got something to say! (Score:2)
Re:I've got something to say! (Score:3, Interesting)
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.
Re:I've got something to say! (Score:3, Informative)
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.
Re:I've got something to say! (Score:3, Interesting)
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.)
Installing from source on an RPM/DEB system. (Score:3, Informative)
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 [labix.org] 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
Re:The point is new approach (Score:2)
On the contrary, it makes RedHat stupid, because the reasonable thing to do would be to take the good package management system that already exists -- namely, dpkg and apt -- and just ditch RPM in favor of it!
What good would that do? If you don't have the dependencies the program isn't going to work, and letting you install the package anyway won't change that!
By the way, apt and Portage come a Hell of a lot closer to your "ideal package system" than RPM does. Maybe you should switch to a less brain-dead distro.
Re:How can anyone take RPM seriously? (Score:2, Interesting)
That bug thread is hilarious. It sounds like Jeff Johnson's departure is the best thing that could possibly happen to any project.
Comment #22 From Jeff Johnson on 2004-06-25 08:13 EST [reply](Posted as someone who came to Linux with RedHat 6, then gave Debian a try when I upgraded to a brand new system and needed to reinstall -- and discovered RH's braindead package "management" wasn't actually normal, and never touched the wretched thing again.)
Re:fuck dependency hell (Score:4, Funny)