Slashdot Mirror
URPMI For Fedora Core 2
Jaroslaw Zachwieja writes "Stefan van der Eijk, the autor of Slbd - automated tool to rebuild distributions to different architectures/processors in a sanitized environment, has published set of RPMS of URPMI for Fedora Core 2. The only usage difference is that it uses hdlist instead of compressed hdlist.cz known from Mandrake. Are we one step further towards Cross-distro RPMS?"
So, what's the difference betweem urpmi and yum? I thought urpmi is equivalent to apt/yum (at least it was advertised as such in the context of Mandrake), but apparently that is not the case...
Save your wrists today - switch to Dvorak
Seriously, is:
make
make install
Really that hard that we need cross distro RPMS?
configure; make; make install does nothing with dependencies. If you, for example, don't have qt development headers on your machine, it just croaks.
Save your wrists today - switch to Dvorak
And besides, if it makes my life even a little easier, I'll be pleased.
- Yum
- up2date
- apt (synaptic)
- urpmi
All of which get out of sync with each other and your system. Sigh.``Seriously, is: ./configure
./configure. Dependencies can be missing, which you would have to find, fetch, configure, build, and install - manually. Also, configure scripts are usually buggy (omitting necessary checks, and performing many unnecessary ones).
./configure wiping out the files in your home directory? I put more trust in my distributor than in random people who wrote the software. Not even so much that they would put in trojans, but how is the security of their server?
/usr/bin et al, this would be easy. As it is, however, they put files all over the place. Good luck figuring out which files belong to the package you want to remove.
make
make install
Really that hard that we need cross distro RPMS?''
I hope you don't really think so.
First off, autoconf configure scripts take a long time to run, and if the package is of any complexity, the compilation will also take a long time.
Secondly, all sorts of things go wrong during
Third, make install is typically run as root. Do you trust the script not to install any trojans? How about
Fourth, software built and installed from source can be a bitch to uninstall. If it installed in its own directory, possibly creating symlinks in
Fifth, packages often need some tailoring to fit in well with your distribution (think menu entries, file locations, etc.) With prepackaged software, this has been done for you.
All in all, a good package manager beats compiling from source any day. Debian's package management tools are very very good, and the reason I prefer Debian over any other distro. They resolve dependencies automagically (which RPM-based distro's are finally beginning to get working), and if you want, you can build the package from source with all the tweaks you want.
Please correct me if I got my facts wrong.
Yes, people keep repeating this nonsense in every Slashdot discussion about packages and dependency resolution in Linux.
I'll take this slowly. There is a problem, a serious problem, that affects many people. It's that software which is not in the distros repositories is too hard to install.
The solution is not "just use Debian because that has everything". Firstly, not all software is in Debian, and some never will be - proprietary software that does not have Debian packages and cannot be repackaged, for instance. Secondly, not everybody wants to use Debian.
Some people like the graphical installers, branded graphics, fast release cycles and tightly integrated desktops that distros like Fedora, Mandrake and SuSE provide. Even if Debian provided all these things are more, there would still be non-Debian distros that people wanted to use. Debian has had years in which to wipe out the competition with its superiority, it has not happened and probably will not.
Even if Debian was the only Linux distribution anybody used, it would still not be a "solution".
Both in unstable and - yes! even in experimental - distro packages are frequently out of date or wrong. The Wine and Mono packages have this problem for instance. For Wine Gentoo is a particularly bad offender. It routinely causes a support nightmare.
They are out of date or wrong because the traditional Debian orthodoxy that centralised packaging works best is also wrong. Think about that for a moment.
I'm sure you're dying to tell me why I'm wrong, why Debian/Gentoo packagers with a guru-like understanding of Debian/Gentoo policy will always do a better job than a hapless developer, and why having all the packages in a central place allows for better "integration".
I'm not going to name names, but I have seen far, far too many flat out broken packages that are excellently integrated with their distribution but are nonetheless wrong. In some cases, they would not even start. I'm thinking primarily of Wine here because that's what I know. Wine is not exactly difficult to install, especially not in the latest versions yet somehow people still get it horribly wrong. I know from talking to other developers though that once you bring up this taboo topic, all kinds of horror stories come out of the woodwork. Brokenness on Debian, on Gentoo, on Mandrake, on Fedora ... the list goes on and on.
Mistakes include not shipping critical files, shipping them in separate "optional" packages when they aren't optional at all, shipping the right files but putting them in the wrong places so the app can't find them, incorrect modifications to system settings based on flawed understanding on the behalf of the packager, oh and the worst - applying random patches which either aren't sent upstream or are so hacky and/or incorrect that they're rejected but still applied downstream.
All these problems cause support nightmares for the developers who at the end of the day actually know how to install their software. Projects don't outsource documentation writing, or usability, or optimization, why should installation be any different?
The Debian approach has many other problems. It doesn't scale. Keeping all the packages up to date requires horrific amounts of manpower and these distros still have problems doing releases. The problem affects every distro: a few days ago I installed Gimp into Fedora and found that it was a 1.3.x prerelease package! Gimp 2 has been out for ages now, and it's still out of date. Desktop Debian basically does not release, you have to use unstable to get a modern system and risk occasionally being locked out of your own system (eg, pam problems) and the like, and Gentoo has given up on that entirely and simply marks a snapshot 4 times a year as their "release".
The right solution to this problem - for eve