URPMI For Fedora Core 2 246
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?"
Re:Who needs em? (Score:5, Interesting)
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.
Yes please. (Score:5, Interesting)
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?
The lost Newbie blinks... (Score:5, Interesting)
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.
RPM Lacks Security Checks (Score:4, Interesting)
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.
Re:urpmi vs yum (Score:5, Interesting)
The difference is GUI (Score:3, Interesting)
Re:Who needs em? (Score:3, Interesting)
configure; make; make install does nothing with dependencies. If you, for example, don't have qt development headers on your machine, it just croaks.
True. I'm amazed that Portage isn't ported to RPM-based distros yet. It handles compiling source gracefully, including dependencies. It can also install binary packages. To me, it's the perfect tool for the job.
Different Issues (Score:4, Interesting)
The other issue, the one about being able to write source RPMS (.src.rpm files) that work in several distros, has to do with the different distros standarizing on the RPM macros, file naming conventions, version schemes and so on. It is all in the Back End. It would be great of course, and it would save a lot of duplicated efforts for the different distributions.
What would be even more interesting as a further step, would be to be able to massively build source RPMS from the RPM front end (be it URPMI or whatever), a la gentoo. This is, to provide a systematic way to get the RPM front end to download and build all the SRC RPMS you need to install the package you need (assuming you can't install these dependendencies from binaries). This would help users compile packages from other distros or from third parties in a painless way.
Little-used advantage of RPMs? (Score:2, Interesting)
Re:Yes please. (Score:3, Interesting)
Of course, you could enforce standards so tightly that there's only one implementation (yours). The real art is to create a standard flexible enough that I can do what I want (need) to without "breaking" your standard.
Mabye you don't want stuff in
Sorry to burst your bubble, but similar problems exist in Windows, you just have to install more software. Nearly all vendors are consistent with themselves, but they do not agree with "the other guys" practices.
Zero Install (Score:3, Interesting)
No more keeping lists of available packages on your local system, or worse, manually tracking dependencies. No more packages not being available for your distro. No more compiling from source. Instead, click and you've got it. I couldn't think of a more user friendly way to install software.
The other great advantage is that it integrates well with both the Web and the local system. With Zero Install you can click and run programs like Java applets, but they will _really_ integrate with your desktop, and _really_ run at native speed. Now hopefully we can kick some bloat out of applications so that they don't take a day to download.
Cross-distro packages is what I need (Score:2, Interesting)
But what I want is cross-distro packages. That would be really useful: how many times I needed that package from kde-apps.org, but I could not install it because it was only available for SuSe and Mandrake and not for Fedora!!!
Well, actually I could install it if I was a serious hacker (take the scr package and hack it so that it works on Fedora), but I am not.
Cross-distro would be very useful for developers too. Supply just one src package and your application can be compiled and installed on Suse, Mandrake, Fedora...
Please read the article on cross-distro pkgs referenced in the news post. Here's the text, in case of
Purpose
The purpose of this paper is to investigate & document to see if it's possible to create src.rpm packages that can be compiled on different distributions. The current Linux distribution landscape features a large number of distributions, each serving their own goal / purpose. All of these distributions contain core functionality, which is maintained by the respective distribution builder. Next to this core functionality, users often require more functionality. Often users compile software on their distribution or produce rpm packages. Unfortunately, this work often needs to be repeated for every distribution because of lacking packaging standards
Re:apt (Score:2, Interesting)
- Chroot support (configurable with an option like --root);
- Media support (configurable with an option like --media cooker_main,cooker_contrib). With yum and apt it seems to be possible, but then you need to point them at a different configuration file;
- Speed. On my Fedora box urpmi is *much* faster than yum. Yum seems to need to recheck all the header files before it'll do anything. Urpmi just goes and does it;
- being able to query dependencies to find the "redundant" dependencies (less BuildRequires = better).
Regards,
Stefan van der Eijk (author of slbd)
Re:Little-used advantage of RPMs? (Score:3, Interesting)
Here's some more RPM-fu:
- rpm -qf somefile, reports what package any file belongs to (as in parent)
- rpm -ql somepackage, reports where all the files of a installed package are
want to see where the dhclient configuration files are? rpm -ql dhclient |grep etc, presto (or use -qc)
- rpm -qpl somepacakge.rpm, list where files in a package will be installed to before you install it.
- rpm -qpi somepacakge.rpm, get all the information such as builder, package description etc. from an uninstalled package.
- rpm -qa, list all installed packages. Combine with grep for lots and uses.
- rpm -qp --changelog somepackage.rpm, get the full ChangeLog for a package. This is great for example for checking what's new in that kernel update package as Red Hat will list every patch they add and bugzilla number.
- And of course plain ol' rpm -q package, report the version of the installed package. There's a ton of stuff you can query, pre and post install script contents, arch, etc.
And remember, RPM is completely network aware. rpm -Uvh ftp://someserver/somepackage works. Hell, you can use the above mentioned queries on packages without downloading them first. Grabbing the ChangeLog remotely is very useful.
Re:Who needs em? (Score:3, Interesting)
Because they are time saving. The mac handles installs very poorly for instance. One click is a beautiful dream but not worthwhile in practice. Even intermediate users want to change options alot of the time.
What is poor is your installation class choices. With linux we don't have to care about sounding professional like commercial offerings.
A few sample possibilities:
"I Intimidated, figure all this out for me."
Picking this and clicking next will install using all defaults without asking another question unless it cannot continue (lack of diskspace or some such).
"Beginner"
Basically the same sort of simple questions asked by a windows installer now. Where to install it, do you want a shortcut on the desktop.
"Intermediate"
Configuration choices, both general and specific, anything that doesn't take knowledge of programming to understand.
"Advanced"
All available options, as well as general config schemes (advanced doesn't mean i should have to set EVERY option, just that I want them at my fingertips).
"But some people would prefer to take the easy way out, and require the user to make all the decisions."
The problem with this logic is that linux packages require all the configuration to be done after the fact. Sometimes hours of pointless reading through options in conf files to set one or two of them.
And because there are so many, you might do this several times before remembering what the option you needed to set is without going through most of the conf.
With an install wizard, postfix for instance could ship ready to go out of the box with no additional configuration by asking just 1 question, local subnet. Now you have to find and edit the conf file, if your not particulary familiar with postfix that means reading about 100 sometimes ambiguous options to determine if you need to set them. For most people the end result is that they needed to set ONE thing out of all those options.
Just about every package should be fully functional and configured upon installation, not just chucked on the drive.
Re:Who needs em? (Score:2, Interesting)
Production servers usually do not have a compiler available.