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?"
URPMI can do pretty much everything apt can do. It is really no better or worse. Apt has more conveient commands for some things, URPMI does for others.
Same shit, different stick really.
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
At least for us Debian-fanatics...
alien works perfectly well for importing rpms and solaris packages... never failed on me.
(Although in some cases a little directory tweaking might be necessary, but that`s really not that much of an issue, at least IMHO)
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.
RPMs can be considered the "Install Shield" of Linux. Yes compiling from source is easy and can be better...but when was the last time you compiled something like KDE or Gnome or even OpenOffice.org from source?
Last time I compiled just the kde-base it took over 12 hours. When a RPM would do the trick in less then 5 minutes. Sure, you may lose some of your precious 'performance tweaks' but you didn't have to wait a day to use it!
BTW, I use Gentoo and love it so I'm not some corporate brainwashed RPM troll. But I can see the benifits of RPMs in a more 'commercial' environment.
"Some things have to be believed to be seen." - Ralph Hodgson
I was introduced to chroots not to long ago and this made my life a little more simple. Just create a small partition of your disk, install a distribution there, don't update the boot partition and move the new dist to a directory on your system. Then just cd into that dir and chroot. Whammo, instant mandrake/suse/redhat/fedora. =)
Atleast for devel purposes.
I don't know much about windows but I imagine that this is one thing that they've managed to nail down. Something created on XP have a fair chance of running on other windows. Or am I misinformed?
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
*blinks*
.....
I think I speak for all long term windows users here when I say.... Huh?
I've only got the faintest idea what this article is going on about, but since I'm a Fedora user with a gripe about installing software on linux, I'll brashly comment anyway.
RPM is good. I love RPM. I can't imagine where I'd be without that lovely self contained, self extracting package that Just Works(TM). Of course sometimes it dosen't Just Work, like when it was built for a different distro, which is very annoying.
Still, it's either that or configure,make,make install or a big gcc -lSDL - lSDL_image -lGLU etc..... for about 50 files. And while these things aren't rocket science, not having a double click to install makes my Linux life all the harder. I'm too long in the windows universe perhaps, but I still like RPM. Now if only it had a GUI.
But on the other hand, will self installers lead us down the path of mindless users, spyware and spam boxes with
embedded linux(the horror)!!! Do we tread the path of usability at our peril?
P.S.
What's hdlist.
May the Maths Be with you!
This worries me a bit. I personally cannot endorse the use of the RPM system globally until it more stringently ensures package validity.
The RPM system has virtually no assurance of GPG key identification. Basically, if a mirror (or any website that serves RPMs) pushes out malicious RPMs, the GPG check by the RPM installer gives NO warning if the RPM isn't encoded at all, and only a passing warning if it doesn't match the RH public key.
This is a potentially huge hole in all RPM based distros, as was demonstrated to me recently by a manipulated RH RPM which, when installed, deleted the iptables rules file and various other things. Yet, the RPM system barely complained about the GPG mismatch and installed anyway (without telling what it did either).
If we're moving toward cross-distro RPM system, it is multiplying the potential problem. I think this needs to be addressed before such a system is adopted by other distros.
The one thing I miss since switching from mandrake to fc2 is urpmi.
So you don't miss your boot sector?
*drumroll*
Sure, it's not really a problem using DAG or some other repository, apt, yum etc, but urpmi is at another level (at least for mandrake).
Isn't that mostly an issue with available repositories, as opposed to software that does the fetching and installing?
Save your wrists today - switch to Dvorak
- 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.
Can't you just use up2date for a yum gui? I did this on Fedora Core 1 & 2.
And apt-get is supported by more and more RPM based distro's, including Fedora. Dragging out apt at this point as an argument for Debian packages is a strawman - Apt haven't been tied exclusively to Debian for a long time.
Each time this discussion comes up I wait for arguments as to why Debian packages are supposedly superior, and why it matters, but so far I have yet to see any arguments presented with actual reasoning behind. I'd love to know what's so great about them... Somebody care to try to enlighten me?
There is no apt vs rpm as there is no urpmi vs dkpg. it is like comparing a beer (liquid) with a beer can.
APT is a great management tool. But it is not a packaging format/tool.
APT already works with Debian, debian dkpg based distros and some RPM based distros as:
- Conectiva (they ported to rpm and support apt use)
- Mandrake (at least for the cooker)
- Redhat and Suse (thru 3rd party prepared mirrors)
An advantage of URPMI over APT is that URPMI can do small updates instead of taking the
whole package list and putting it in a big "rpm -Uvh" command line.
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