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?"

Comments

apt

[selfabuse]

a cross platform package system would be great, but wouldn't something like apt with dependency resolution be much better then RPM? (yes I know there is apt for redhat/fedora)

Re:apt

[tolan-b]

apt for redhat/fedora uses RPM packages, and includes deps resolution. same for yum

Re:apt

[Anonymous Coward]

RPM has dependency resolution too -- the only thing apt has going for it beyond RPM is that Debian, the most prominant user base for apt, keeps their dependencies in great shape.

If RedHat or SuSE were to have the same army of developers managing packages and ensuring their dependencies are all assigned correctly, they'd be just as effective as Debian.

Re:apt

[senzafine]

I agree. But hopefully that's the next step...to have something to resolve dependencies cross platform. I know that when I first started using linux that dependency hell was my main reason to revert back to windows. Once you get used to it...it's ok. But for newbies...that would be really sweet to have a uniform package system w/ dependency resolution.

Re:apt

[RAMMS EIN]

URPMI does dependency resolution. And apt has been ported to work with .rpms besides .debs.

Still, I sigh each time a new RPM-based distro or tool is announced. Why couldn't they just adopt Debian's packaging tools? They were there first, and worked well from the beginning. RPM has been a nightmare.

Re:apt

[Short Circuit]

Try using apt. I know it works well for Debian, but I haven't really given it a shot on RPM-based distros.

Re:apt

[RAMMS EIN]

Basically, .deb isn't that much better than .rpm. It is apt (the software that downloads packages and dependencies) that has made Debian's package management superior to what RPM-based distro's provide. That, and the size of Debian's package repositories (I think Debian provides more packages than any other distro) makes dependency resolving really work.

One final argument is that .deb was there before .rpm. Red Hat decided to roll their own, incompatible format, which was not only Evil and Rude, but has also caused many people to have an subobtimal experience managing packages.

Re:apt

[vk2]

Come on .. dare to say it .. gentoo

Re:apt

[FubarPA]

No, RPM itself does not have dependency resolution. If you try to install an RPM you downloaded, but you forgot about a dependency, it's not going to go download that dependency for you. Using apt, yum or urpmi is what does the resolution for you.

Re:apt

[rsd]

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.

Re:apt

[dirty]

I really don't think your point about .deb being older than .rpm is true. I have nothing other than memory to back this up, but I'm prety certain that .rpm was around before before the Debian distro existed.

Re:apt

[NED260]

I've been looking at apt, yum to include support for them in slbd. It's been quite a strugle, since both apt and yum don't have the featureset that urpmi currently has and I'm using:

- 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:apt

[perlchild]

You neglect a few advantages of .deb

Like the fact that hand-modified config files are merged if at all possible when upgrading(they aren't just renamed/replaced like with rpm).

That and the fact that Debian has standards for the behaviour of packages, and expects you to follow them. (The existence of standards is not the advantage, their quality and applicability to the stability of the system is) Of course, that's probably why so few third parties develop for Debian, they're fine with throwing a ./configure;make;make install through checkinstall to generate a package, but actually maintaining a package, and following the rules to make sure the package actually behavesis beyond most of them.

That doesn't mean it would work for cross-distro packages though. Suse/RedHat/Mandrake/etc would have to agree to package naming in a consistent manner... If gd2 is called libgd2 in redhat and gd2libs in another system, which is the correct one to specify in a dependency? If you want to install redhat's apache, and it depends on libgd2, how would your gd2libs supply the dependency? Do you need to install gd2libs and libgd2? What if they both supply /usr/share/docs/gd2/README or /usr/lib/libgd2.so.0 ??

Then there's the init scripts. Not only do each distro have a different init script method, but if somehow you replace the standard method in one distro(say you use runit or some other init replacement) not a single one of them handles that gracefully.

Then there's the real reason cross-distro doesn't exist:

1) Some distros make you pay for some "deluxe" packages, if you can replace them with packages from another distro, where it's free(setting aside the relative quality of packages, and just from a marketing standpoint), you are removing value from the deluxe package

2) Distros with the best install procedure would be afraid to be used to install a base system, and a few tweaks later, have all the "optional" packages supplied from another.

3) Third parties. If X builds a third party package in rpm format for distro X, it doesn't want to support distro Y, with a sufficiently advanced cross-distro capability, they'll never find out they were supporting distro Y either. But, more importantly, if Distro Y got into a financial arrangement with Third Party A, to supply package B that only works with Y, and X can add dependencies from Y, X can run package B.

1) 2) and 3) are political/marketing/social in nature, and have nothing to do with the superiority or inferiority of a packaging system/package tool.

Re:apt

[trashme]

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.

Huh? Are you saying that apt can't upgrade just one package at a time? That's absolutely false.

apt-get install mozilla-firefox

There. I just upgraded Firefox and any dependant packages that must be upgraded. No other possible updates are installed.

Re:apt

[rsd]

"Huh? Are you saying that apt can't upgrade just one package at a time? That's absolutely false."

No.

I mean that if you do an "apt-get dist-upgrade" or similar task, apt will download
every necessary package and do a:
rpm -Uvh [every package that will be updated here]

URPMI can break the "[every package that will be updated here]" list into small upgradable
islands.

I think this approach cleaner. You can observe that during an Mandrake upgrade thru Drakx if you change to
the log console.

You can argue that it is not a problem if apt works that way. However, I have experienced problems with bad packaged
packages that made the "rpm -Uvh" abort in the middle leaving my system unstable.
It's true that it is not a apt problem, but with this kind of feature urpmi would make less damage if this happened.

Re:apt

[juhaz]

I think you vastly underestimate age of RPM and overestimate age of Deb.

There was no "superior" debian package format from the beginning, they are of almost same age. RPM's precursor RPP and dpkg's predecessor were introduced in 1994 and both RPM and modern dpkg (though the package format DID go trough another change) in 1995.

If RH had started in, say 1996, maybe they would have "adopted Debian's packaging tools, assuming they were good enough at that point", but alas, they started the development of package managers at the same time and so that could not happen.

Re:apt

[djcapelis]

Gentoo has a larger package base actually I believe?

If not... I imagine they will soon... far easier to write ebuilds than to package .debs

Re:apt

[creathon]

Can apt be used to install .deb's on Fedora? Could apt be used to install exe's (inder wine) as well as rpm's, debs and tgz's?

Who needs em?

[daringone]

Seriously, is:

./configure
make
make install

Really that hard that we need cross distro RPMS?

Re:Who needs em?

[ultrabot]

Seriously, is: ./configure
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.

Re:Who needs em?

[kyknos.org]

the problem is it is not as easy as you describe in many cases. I am not a beginner, but when i tried this at gimp pre2.0 something, i got dozens of errors. precompilled rpm worked fine. so for normal users and for linux on average desktop precompilled software is not only usefull but probably necessary

Re:Who needs em?

[Gorath99]

Seriously, is:

./configure
make
make install

Really that hard that we need cross distro RPMS?

It is if we ever want desktop linux to take off.

And besides, if it makes my life even a little easier, I'll be pleased.

Re:Who needs em?

[Short Circuit]

You'd give up automated dependancy checking and downloading in order to run someone's build script?

Besides, the five-step build process isn't universal. Try compiling Nethack+(any GUI for it)...I find configuring my kernel easier.

On the other hand, I've had to install apps that just came with C files, and no list of dependencies.

Re:Who needs em?

[mahdi13]

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.

Re:Who needs em?

[RupW]

Another thing is that there's rarely, if ever, a "make uninstall" but that's easy with packages. Sometimes it's easy to manually hunt down all bits and rm them, sometimes it isn't.

Re:Who needs em?

[daringone]

configure; make; make install does nothing with dependencies. If you, for example, don't have qt development headers on your machine, it just croaks.

I understand what you're saying. However, I think most people, when possible, will tell someone to compile from source before using an RPM. I know this for fact with both Apache and Qmail. Granted, these aren't your run-of-the-mill desktop applications, but just an example. With that in mind, most applications will have a list of what dependencies are needed to compile the application. Maybe I haven't used RPMs enough to know why/how they are able to fulfill dependencies (I was gently pushed towards always compiling source early in my *ix newbiehood) but I would think you'd still have to install appropriate RPMs to satisfy RPM dependencies too wouldn't you?

Re:Who needs em?

[ultrabot]

. Maybe I haven't used RPMs enough to know why/how they are able to fulfill dependencies (I was gently pushed towards always compiling source early in my *ix newbiehood) but I would think you'd still have to install appropriate RPMs to satisfy RPM dependencies too wouldn't you?

Yes, but the hadnling is automatic these days with software like you and apt-rpm.

I guess you'll have to experience "yum install kde" and see it fetch a zillion packaged to appreciate the work it does for you.

Re:Who needs em?

[daringone]

It is if we ever want desktop linux to take off.

This is true... but by that time we should also have the little "Next > Next > Next > Finish" graphical install programs that make Windows/Mac so popular and easy for Joe Doorknob end-user too.

Re:Who needs em?

[Eggplant62]

I guess you'll have to experience "yum install kde" and see it fetch a zillion packaged to appreciate the work it does for you.

Oh. As if that's not easy with urpmi??

urpmi.update -a (updates all media sources)
urpmi kde (grabs latest kde with dependencies)

samey same

Re:Who needs em?

[bustersnyvel]

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.

Re:Who needs em?

[DarkSarin]

Hence the whole idea behind compile everything distros like gentoo, which not only handles dependencies, but also handles compiling.

Now if gentoo only had a simpler way to install everything... (but they do have a nice upgrade path!)

Re:Who needs em?

[RAMMS EIN]

``Seriously, is: ./configure
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 ./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).

Third, make install is typically run as root. Do you trust the script not to install any trojans? How about ./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?

Fourth, software built and installed from source can be a bitch to uninstall. If it installed in its own directory, possibly creating symlinks in /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.

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.

Re:Who needs em?

[BenjyD]

Erm, of course it is. Compiling your own software:

- doesn't resolve dependencies
- requires dev headers installed
- takes forever
- results in cryptic error messages on failure
- has no uninstall
- is confusing for many experienced users, let alone newbies
- often requires cryptic options (--enable-foo etc)

I've used linux for years and I still consider installing from source a last resort. It may have more geek-cred, but that doesn't make it a good thing.

Re:Who needs em?

[g0qi]

Seriously, is:

./configure
make
make install

Really that hard that we need cross distro RPMS?

I don't know how you can go to war about linux on the desktop, and still assume grandma and little johnny are going to have compilers installed on their system. And talk about the bloat.

Of Course we need cross distro RPMS.

Re:Who needs em?

[ultrabot]

Oh. As if that's not easy with urpmi??

Comparison was with configure/make/make install, not urpmi.

Re:Who needs em?

[ebuck]

Cross distro RPMS would allow you to do the same, except you gain:

1. The ability to build on one machine yet install on another.
2. The ability to build on one architecture yet install on another.
3. The ability to perform you compiles in one highly observed area instead of tracking down multiple remote compilations and debugging them from afar.
4. The ability to not worry about current compiler installation and build tools on all platforms, just the one you're developing / building on.
5. The savings in time by building once per distributiable instead of once per installation.
6. A guranteed uninstall path, even if the installation distributable is removed or damaged.
7. A database of installed files allowing mapping of a file to a package, listing of all files in that package, and what packages require and depend on this one.
8. Easier / automated patch application for those times developers have overlooked your particular platform.
9. The gurantee that two platforms with the same RPM have the same bugs / issues / configuration / etc.
10. The ability to see which (if any) files have been modified since the original installation.

So if your supporting that one computer at home which also doubles as your development box, and you're willing to waste away portions of your lifetime doing exactly what others have already done by fixing those compiler warnings / errors / learning someone else's source code better than them. Then, I guess, they are about equivalent solutions.

Re:Who needs em?

[Kick the Donkey]

God. Please. No.

The last thing we should want to see is an Install Wizard on Linux. The software should be smart enough to install itself, without any help on my part (unless I want something special, like a different install directory, or some such). We're almost there with apt-rpm-autopackage. Dependecy resolution is the tough nut to crack for all distros.

Why do people think that Install Wizards are so easy? For someone who has never installed software (or, used a computer beyond checking email, etc), they are not. To an experienced user, most of the questions are un-important (they just accept the defaults). But, to a true new user, all of the questions are important, because they don't know what's not important! All they see is this baradge of questions: Install path, menu location, modules, etc, etc, etc. Those kinds of questions could be overwhelming.

The install wizards where the product of lazy programers who wanted to off load the resposibility decision making during the installation process to the user. Simple as that.

Linux is on the right track with simple commands like urpmi gimp. No questions. Just install the damn thing.

People that want install wizards are probably more likley to throw the baby out with the bath-water, too. The pkg systems on Linux are close. We need dependcy resolution, and cross-platform menu entries (so users know where to look for the new software). Get those, and we've got software that is easy as pie to install.

But some people would prefer to take the easy way out, and require the user to make all the decisions.

Re:Who needs em?

[magefile]

Don't forget the other nice thing about RPMs - if you do want to compile it yourself, you can then make an RPM, and either roll it out to tons of boxes at once, or reinstall the same (customized, optimized) RPM every time you reinstall your distro (yes, I've done this a few times ... don't ask why).

Re:Who needs em?

[dirty]

Because some of us are running pII-300Mhz linux machines that take forever to compile. Binary packages are a good thing. I can do a "yum update" and update about 50 packages in a half hour or so. I don't want to think about how long it would take me to upgrade them all compiling from source.

Re:Who needs em?

[shaitand]

Yeah, and if only compiling everything didn't take up to 24hrs for just one package and it's dependencies!

Re:Who needs em?

[shaitand]

And almost all sourcecode comes with those instructions, most don't give much documentation beyond that. And 98% fail EVERY time if you do exactly that and don't use any additional options or provide additional dependencies.

Re:Who needs em?

[shaitand]

"Why do people think that Install Wizards are so easy?"

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?

[mufasio]

RPM is great for distro packages but it utterly sucks for 3rd party apps.

"install shield" for linux exists. here is where it has lived for years.

"install shield" for linux doesn't provide any advantages over RPM for 3rd party apps because it doesn't handle dependecies. The only way for it to work effectively is for the programs that use it to be staticly compiled which defeats the advantages of using dynamically linked libraries.

Sadly the only way to get 3rd party apps to work seamlessly on all platforms is if the developers support each and every platform, they staticly compile their program, or if there is a cross platform standard for handling dependencies (which is highly unlikely to happen) and the dependencies are available for all platforms (which they are all not, for example gtkmm is not officially available for Fedora, etc.).

Re:Who needs em?

[DarkSarin]

it generally doesn't on modern hardware--openoffice takes about 3 hours on my athlon xp 3200+ (512mb ram, YMMV).

I haven't installed KDE, so I can't vouch for that, but I am guessing that it wouldn't take 24 hours. Just a thought though.

Re:Who needs em?

[slayer99]

Mmm, supposing your system does not and will not have a compiler installed?

Production servers usually do not have a compiler available.

Re:Who needs em?

[fataugie]

Well, speaking from experience, I have compiled gentoo including kde on a AMD 450 with 392M of RAM, and it did take 24 hrs. An XP would certainly be faster, but I bet it could easily go 8 hrs with all the dependancies included...

Just for comparison, the total install took over 2 days with KDE taking 1 all by itself.

Re:Who needs em?

[DarkSarin]

I'll tell you what--watch my journal and the next time I re-install (which I plan to soon, since I missed somethings the first time that I want to fix this time), I will keep track of how long things take to compile. I can't promise shocking accuracy, since I frequently go to bed immediately after beginning a long compile (its a great way to pass time...), but I'll give it a shot.

Re:Who needs em?

[shaitand]

Actually KDE takes more like 8-10hrs and as much again if want gnome also (which most do) on an Athlon XP 2600 with 512mb DDR.

I was exaggerating a tad. But your average computer in use today is MUCH slower than my athlon, in fact it's more like p3'ish to t-bird.

Don't get me wrong, I love gentoo. Although there are definately holes in the documentation, what is there is an example how documentation should be done. And portage is a dream in terms of doing what it does and doing it well. A gentoo system is certainly a hell of alot easier than a LFS system.

3hrs for open office compared with 30min (assuming it has to be downloaded as well, probably less) for the rpm, it's a hell of a difference.

The worst thing though, is after spending all the time to compile my gentoo system completely from scratch, along with all the applications I wanted on it. And then to configure everything (most of the confs are in the raw form they are when you download the tarball, which is almost never usable out of the box).

Anyway, after spending the time to get everything installed the way I like it, a full weekend of nonstop compiling and then tweaking and app installing over the next week. The system lasted a couple months, rock solid and very fast (no matter what anyone says about minimal gains compiling from source). My motherboard then died, when I ordered a replacement board they sent me the wrong one... instead they sent me what was the top of the line p4 board at the time.

By this point I was starving for computer and decided to give a p4 a shot (not even thinking about my fully athlon optimized OS). Naturally it wouldn't even run the bootloader.

Somewhere in all that I figured out, I uninstall and install applications daily. I change hardware very very frequently. As much as I loved the performance and pride that came with a gentoo system, I just didn't have time for one.

Re:Who needs em?

[DMUTPeregrine]

but when was the last time you compiled something like KDE or Gnome or even OpenOffice.org from source? About two days ago, installing Gentoo. (Note, I actually agree with you here...)

Re:Who needs em?

[DarkSarin]

I agree--gentoo is not for those who frequently upgrade their processor...or other key components...frequently (exception: video card of the same variety).

I still enjoy it though.

Re:Who needs em?

[mahdi13]

but when was the last time you compiled something like KDE or Gnome or even OpenOffice.org from source? About two days ago, installing Gentoo. (Note, I actually agree with you here...)

And OpenOffice is STILL compiling!
emerge openoffice-bin
it's a binary install, but doesn't take a week to compile. I just don't have 36 hours to give to installing a single app...

URPMI does depndancy resolution

[brunes69]

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.

Re:URPMI does depndancy resolution

[ninjaz]

It is really no better or worse. Apt has more conveient commands for some things, URPMI does for others.

I've used Debian in the past and have been using Mandrake for about 3 years. While urpmi is in the same application category, I wouldn't say "no better or worse". In my experience, apt wins hands down. I wish Mandrake would use apt-rpm instead of urpmi.

When I used apt and something bad happened, like a lost internet connection, apt-get would pick up on the byte it left off (as would dselect before it). I never had any connection difficulties with it.

urpmi, on the other hand, sometimes requires using the --wget option, because it will hang trying to download with its default curl (why is urpmi using external programs for download, anyway?) And, when something goes wrong, it tends to want to re-download everything, not pick up exactly where it left off.

I use Mandrake because it's kept up-to-date, menus are synced across window managers, and I can order cheap CD's to upgrade (I have a modem connection at home). urpmi is a weakness for me compared to apt-get, not a strength.

Re:URPMI does depndancy resolution

[alaaosh]

you can make wget the default download tool by editing /etc/urpmi/urpmi.cfg

and if you use rsync sources it will resume your downloads.

personaly I always use rsync sources, this way I only need to download the difference when I update hdlists.

Re:URPMI does depndancy resolution

[ninjaz]

you can make wget the default download tool by editing /etc/urpmi/urpmi.cfg

My whine is that I think http/ftp download should be more integrated into urpmi to begin with. A solid built-in mechanism would obviate the need for switching around downloading backends. It's clumsy to have to switch around backends for something so basic and which had been solved by Debian years before.

and if you use rsync sources it will resume your downloads.

Very cool! Thanks for the tip. :-)

rsync sounds like the optimal way to approach this anyway, since ftp is aging and was designed before NAT was pervasive (active vs. passive).

urpmi vs yum

[ultrabot]

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...

Re:urpmi vs yum

[Eggplant62]

I've only read about yum, but I've used urpmi with Mandrake for years. I can tell you about how urpmi works:

1. urpmi.addmedia -- allows a user to define new media (cdrom, ftp, nfs, etc) to be used for getting updated rpms and dependencies. Graphical tool is gurpmi.addmedia.

2. urpmi.update -- polls the media sources that are not on fixed media and downloads fresh hdlist files if available.

3. urpmi.removemedia -- samey same as addmedia, only in reverse. No graphical tool as this function is available in guprmi.addmedia utility.

4. urpmi / gurpmi -- command line / graphical utilities to download/install new/updated rpms, solving dependencies along the way.

5. edit-urpm-sources.pl -- a GUI tool available for Mandrake to edit the list of available source media.

I keep hearing about yum, apt, red-carpet, etc, and read a lot of confusion about how they compare to Mandrake's tool. I've messed with Debian's apt/get system on my testbed machine, but I keep coming back to Mandrake and urpmi. It's familiar, easy to use and I likes it.

Re:urpmi vs yum

[buchanmilne]

For one,yum is *much*, *much* slower than urpmi at dependency resolution, second, I don't think yum supports retreiving packages via ssh/rsync, and I am sure there are others.

Re:urpmi vs yum

[ultrabot]

For one,yum is *much*, *much* slower than urpmi at dependency resolution, second, I don't think yum supports retreiving packages via ssh/rsync, and I am sure there are others.

Honestly, both points seem rather trivial to me. My experience with yum suggests maximum dependency resolution time of 15 seconds, which is not that big a deal considering that you don't do that too often - and the packages need to be fetched anyway.

Re:urpmi vs yum

[kabloom]

And don't forget urpme which removes packages from the system, like an apt-get remove.

Re:urpmi vs yum

[Styx]

On modern hardware, perhaps. One of my servers (dhcp / nameserver) is a K6-200 w. 192 mb ram. Updating with yum is slow and painful compared to apt-get. Yum also uses a shedload of RAM. Dependency resolution on tha t box can take several minutes.

Re:urpmi vs yum

[buchanmilne]

On a new Dell 1750 server, 'yum install perl-ldap' took well over a minute to resolve dependencies (and a second or two to actually install the packages from the mirror which was one hop away on a Gb connection). On my laptop (with much slower disk and CPU), Mandrake does the whole operation in under 10 seconds.

On both machines, similar numbers of packages had to be installed.

The difference is non-trivial.

Re:urpmi vs yum

[Anonymous Coward]

You forgot
urpmf somefile find what package has somefile

Re:urpmi vs yum

[juhaz]

At least slow dependency resolution, possibly rsync too, is solved by apt-rpm, so what's difference between it and urpmi?

Re:urpmi vs yum

[pyrrhonist]

So, what's the difference betweem urpmi and yum?

If you like what you ate, you say, "Yum!", otherwise you involuntarily make a noise like, "urpmi".

Re:urpmi vs yum

[greenrd]

apt-get fascistically forces you to satisfy all dependencies at all times. Whilst this is generally good practice, there are times when you don't want to do that, and apt-get doesn't even offer you the option. (So much for debian being all about choice!)

Also, I once found a corruption bug in apt-get, and submitted a patch, and it wasn't reviewed for months (if ever). I like to use software that's actually maintained, and I saw precious little evidence that it was being maintained when I tried using it a few years ago.

No need

[alexbartok]

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)

Re:No need

[Otter]

It is no longer 1999* and the era of Debian users making off-topic comments in every RPM story is past. It is now the era of Gentoo users making off-topic comments in every Debian story. Please get with the program.

* Your 2.0.x Debian kernel notwithstanding...

Re:No need

[alexbartok]

lol !
I was trying to point something out which might have been unknown to newer Debian users reading this.

Besides, I'm running 2.6.6 ;)

Re:No need

[Stinking Pig]

aw man, I thought this was the era of Windows apologists and Macfanbots making off-topic comments in every Linux story! I'm so out of touch....

Great!

[kunudo]

The one thing I miss since switching from mandrake to fc2 is urpmi. If it works as well as it does in mandrake, this is very very nice indeed.
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).

Re:Great!

[ultrabot]

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?

Yes please.

[haeger]

This is one of my pet peeves when it comes to Linux. Why do I have to have one RH9, one MDK, one SuSE and one Fedora just to be able to redistribute my package to the largest rpm-based distributions.

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?

.haeger

Re:Yes please.

[FauxPasIII]

> Whammo, instant mandrake/suse/redhat/fedora. =)

Usermode Linux will get you an even more complete experience. This is what we use at emperor linux
to keep our distribution images up to date, all running on one big quad-xeon server.

The main strength of this is that your fake fedora/suse/whatever machine has its own process list and /proc tree to muck around with, and won't reach out and mess with your "host" system.

Re:Yes please.

[ebuck]

Unfortunately, that's exactly what every one of these "incompatiable" distros have and are doing.

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 /opt, but I don't want to test a beta compiler by removing my stable version of the same in /usr/bin. If I couldn't override the installation directory, I couldn't have them both installed at the same time.

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.

Re:Yes please.

[mixmasterjake]

That is true. Something compiled on XP will usually run on just about any XP box.

There are obviously exceptions. Software that works very closely with the hardware, for example, tends to experience more compatibility issues. (games, etc). Also, if you've used 3rd party libraries (and your installer doesn't include them) you'll get run-time errors, obviously.

Once you sucessfully run your installer and app on a out-of-the-box XP machine - it is generally gonna run on all of them.

dpkg !> rpm

[ultrabot]

Still, I sigh each time a new RPM-based distro or tool is announced. Why couldn't they just adopt Debian's packaging tools?

There is nothing to be gained from using dpkg over rpm, really. I'm a debian user, and in fact would prefer if Debian switched over to rpm (which is specified in LSB as the standard packaging mechanism, BTW). Dependency resolution and all that works with rpm as well.

Obviously this will happen, because Debian is, well, Debian.

emerge

[Abit667]

done.

Re:emerge

[EvilSporkMan]

Just go to sleep if you're that impatient. After a few weeks it's mostly just updates anyway, so it's not like the system is unusable.

The lost Newbie blinks...

[ObsessiveMathsFreak]

*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.

Re:The lost Newbie blinks...

[Too Much Noise]

hdlist is the package index that urpmi uses for the given repository. The 'full' version (actually the gzipped hdlist.cz) contains as extra the package info for each package: full file list, notes, changelog (needed if you want to use for instance urpmf - find packages that contain a given filename string). The 'short' version (synthesis.hdlist.gz) contains only the package list and dependencies (provides/requires) for the repository (useful for slow connections, as the full index for mdk easily goes to some tens of megs for main and contrib).

Re:The lost Newbie blinks...

[Black Perl]

I'm a Fedora user with a gripe about installing software on linux ... I'm too long in the windows universe perhaps, but I still like RPM. Now if only it had a GUI.


Just about every Linux distro except Fedora has a standard graphical installer. If that is important to you, I think you may have chosen the wrong distro.

But if you decide to use Fedora anyway, you should be using yum, which is a layer on top of rpm that automatically resolves dependencies. yum is much easier to use than rpm.

Re:The lost Newbie blinks...

[magefile]

Just about every Linux distro except Fedora has a standard graphical installer ... if you decide to use Fedora anyway, you should be using yum

Um ... yum has a GUI frontend. There's up2date which is installed by default (doesn't let you install, but takes care of updates), which I admit sucks, but if you want something non-sucky that does install/remove stuff too, check out Cobind Yum GUI, Red Carpet by Ximian (FC1 only, but probably works on FC2), or Synaptic (you have to compile yourself if you want RPM, but it's only one compile).

This is a bunch of FUD. Besides which, what does a GUI actually add to the package management experience?

Re:The lost Newbie blinks...

[violajack]

Besides which, what does a GUI actually add to the package management experience?

Um...how about the ability to browse avalible packages by category so you can find what you want when you don't know the name of the package. I'm a fan of Mandrake's graphical frontend rpmdrake which works through the control panel. It provided a great transition into the world of linux for me the former-windows-user. People new to linux don't know that xine is a great video player that may not be included in their distro, but if they go browsing in the Multimedia category, they can read a description of xine and learn what it is. You can even search the descriptions, so I could type "video player" and it would show up all the packages that were video players. I simple check a little box next to the one I want, click install, click ok when it tells me what other packages need to be installed as dependencies, and watch it download and install everthing automatically.

Re:The lost Newbie blinks...

[Issue9mm]

"Besides which, what does a GUI actually add to the package management experience?"

Because it lets my wife install the newest version of Solitaire without me having to be bothered at work?

Because it keeps her from having to know which repositories are available?

Because it lets her get the latest security patch from /wherever/ via point and click install, so I don't have to walk her through a bunch of arcane commands involving utilities she may or may not have access to use?

-9mm-

Re:The lost Newbie blinks...

[Platinum Dragon]

This program was once available for Red hat, and did what rpmdrake seems to do now. For some reason, it was never updated for Gnome2, and the Fedora teams seems to have more interest in forcing people to use only Fedora-built packages--at least, this is what I can determine from the horribly limited "Add/Remove Applications" interface.

This may very well get me to switch to Mandrake during my next upgrade, assuming I don't go crazy and just switch to Gentoo instead. Losing GNOrpm, in my opinion, was a huge step backwards for maintaining a Red Hat/Fedora-based system, and I see no reason why its functionality couldn't be combined with yum's retrieval and dependency-resolution capabilities.

Re:The lost Newbie blinks...

[buchanmilne]

Until linux apps start shipping as staticaly built to avoid the dependancy hell that is linux right now ... security vulnerabilities in a widely used library will only require updates to that library, not every application that uses it (statically).

Re:The lost Newbie blinks...

[peter_gzowski]

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.

The more common reason for rpms to not Just Work is that there is a dependancy problem (at least, in my experience). Most rpm repositories (ex. rpm.pbone.net) allow you to filter by distribution and version, so finding rpms that were built for your system isn't too much of a big deal. Dependency problems are far more difficult, and this is what urpmi is meant to resolve (no pun intended). You configure it to use one or more repositories as a source of rpms. It uses the hdlist file on the remote repository to figure out what packages depend on what, and gives you messages like "To install this package you also need to install blah and remove blah. Continue?". You then hit yes, and it just does it all. It all hinges on finding a good repository of packages, though. This isn't too tough thanks to Easy Urpmi.

This does not, however, solve the problem of cross-distro rpms. If there are now FC2 urpmi repos, you still could not configure urpmi in Mandrake to use it and still expect it to work.

Re:The lost Newbie blinks...

[Stinking Pig]

who's us?

Anyway, package management tools are more or less equivalent in their ability to do what they need to do. I'm a happy urpmi user, but I've used up2date and red carpet and apt-get too. Within reason, they work.

The real catch is the double-whammy of repository availability and dependency definition. Basically, if someone isn't keeping a tight hold on the distro and enforcing "this works with that and doesn't work with t'other" rules, the whole package management ideal falls apart.

In other words, tools are no good without people to use them.

RPM Lacks Security Checks

[Tocano33]

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.

Re:RPM Lacks Security Checks

[buchanmilne]

Maybe you should read up on urpmi then.

If warns you (and requires a confirmation to continue) if a package is not signed. It warns you (and requires a confirmation to continue) if a package is signed, but you have not told urpmi to trust packages signed by the key used for the packages in the repository you are using.

That's another advantage urpmi has over all other packaging frontends I am aware of.

Re:RPM Lacks Security Checks

[Linegod]

Did you even bother to RTFP? I can see you failing to RTFA, but the post? The article (and the post) were about 'urpmi', not RPM. urpmi does GPG checking, and will ask if you want to continue when it notices a mismatch, unless passed --no-verify-rpm.

Re:RPM Lacks Security Checks

[Eggplant62]

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.

I call bullshit. urpmi has been doing just this kind of checking for some time now, at least since the version used in Mandrake 9.0 or so. I frequently grab Mandrake RPMS from glarb.org's Penguin Liberation Front and see many a warning about lack of GPG signatures.

Re:RPM Lacks Security Checks

[Eggplant62]

I frequently grab Mandrake RPMS from glarb.org's Penguin Liberation Front and see many a warning about lack of GPG signatures.

I should correct myself here. That's zarb.org, and the the Penguin Liberation Front.

Re:RPM Lacks Security Checks

[ebuck]

How is this informative?

If you don't bother to use --checksig, then you've got a lot of security home work to do. I doubt that RedHat rolled such a package, checksig will allow you to verify the source of your packages (at the cost of collecting a few (trusted) public keys).

Query the package for a correct signature before installation, like so:

rpm -qp --checksig package.rpm

If there's no signature, or it's not a valid one, don't run the installation command.

Kitchen knives are used to cut. If you slice off your fingers due to inattentiveness / lack of training, it's hardly a security hole in the kitchen knife.

You fell victim to one of the classic blunders. The most famous is, "Never get involved in a land war in Asia", but only slightly less known is this: "Never go in with a consultant, when he's got an axe to grind!"

As far a rpm being slient, that's just because you didn't ask. The verbose flag is -v and for really verbose output try -vv.

Re:RPM Lacks Security Checks

[arcanumas]

Gentoo's portage does this type of checks too. But it will not prompt you for confirmation in case of a bad/missing signature. It will not proceed at all.

Re:RPM Lacks Security Checks

[Too Much Noise]

afaict the vast majority (if not all) of the plf packages are signed with the plf key - which should have been imported from the repository by any recent enough version of urpmi. The warnings I'm getting (if any) are usually for contrib packages. Are you certain your urpmi settings are correct?

Re:RPM Lacks Security Checks

[buchanmilne]

And I'm guessing it has a GUI for this too???

Are the ebuild files checked with crypto signatures?

Are sources checked with crypto signatures? What are they checked against?

Are binary builds checked against signatures? I don't think so ...

Re:RPM Lacks Security Checks

[ispeters]

To make an offtopic Gentoo-plug, the portage system checks MD5 sums of the downloaded source and won't continue with the install if the MD5 doesn't match up.

Can anyone tell me why this MD5 thing is considered secure, though? I realise it sounds good, and I was told once that a compromised source mirror was discovered by a Gentoo user whose MD5s didn't match, but if you can manage to hack into a server and upload some tainted source files, what's to stop you from uploading some tainted MD5/gpg signatures, too?

Ian

The difference is GUI

[levell]

The main difference between yum and uprmi seems to be that there is a stable GUI for urpmi. There is the beginnings of a GUI for yum here but I can't seem to get it to work right for me on FC2 using a proxy. (Apt has the synaptic GUI).

Re:The difference is GUI

[Scyber]

Can't you just use up2date for a yum gui? I did this on Fedora Core 1 & 2.

Re:The difference is GUI

[levell]

You can't install new packages with up2date, it just updates the current ones.

Re:The difference is GUI

[magefile]

According to the first page of Synaptic's website, it can be recompiled to support RPMs.

Re:The difference is GUI

[levell]

Sure and I've used it for rpm based distribution with apt but it doesn't work with yum.

Re:The difference is GUI

[levell]

Interestingly, I was just over at the Fedora website as I had heard that the schedule claims FC3 test1 is due out today and I notice that the roadmap says that eventually system-config-packages will be able to install software from external repositories. Woo!

Re:The difference is GUI

[Coryoth]

You can't install new packages with up2date, it just updates the current ones.

Really? I wonder how I managed to install new packages with up2date then. Must have been some odd bug or something that let me do it by accident.

Jedidiah.

Re:The difference is GUI

[hduff]

The Cobind Software Manager works well here. It's a little feature-poor at the moment, but that's to be expected.

Re:The difference is GUI

[jhunsake]

That's hardly insightful, I install new packages (remote and local) all the time using up2date.

Re:The difference is GUI

[juhaz]

Sure it is. Unless you managed to noticed, this was about GUI.

up2date can only install new packages from command line.

Yay, more out of sync updaters

[Anonymous Coward]

so now on fedora you have:

• Yum
• up2date
• apt (synaptic)
• urpmi

All of which get out of sync with each other and your system. Sigh.

Re:Yay, more out of sync updaters

[levell]

None of these updaters keep a list of what is already installed on the system, they all use the rpm database, as long as the repositories you use for them all are compatible (they don't obselete each others packages etc.) then you should be fine.

Re:Yay, more out of sync updaters

[polaar]

you forgot Red Carpet ;-)

Different Issues

[InodoroPereyra]

Having URPMI under Fedora will give Fedora users another Front End to RPM. Is this good for them ? Most likely yes.

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.

Re:Different Issues

[IamTheRealMike]

Why not simply compile the RPM once and have everybody use it? Linux binary portability is good enough for that, you know.

Re:Different Issues

[buchanmilne]

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.

If you RTFA, that's what this project is about. But, first we need a working urpmi and slbd ...

Re:Different Issues

[InodoroPereyra]

Thanks for the feedback. Yes, I RTFA, but I probably wasn't clear in my post. What I meant to say is that the two projects mentioned in the FA relate to two different, although related issues. One is about the front end, another for the back end. I meant to clarify this for people who are not into the details of RPM.

And there is the third issue of using URPMI as a front end for intelligent source RPM compiling. Thanks for the feedback on this last point too. It's great to know that there are folks working on that, and I hope the project is successfull :-)

Cheers!

Ugh, I hope not

[feilkin]

I'm really hoping that RPM does not become the new packaged standard. Debian packages tied in with apt are just so much more powerful and have a much better chance for future expansion. I seriously think that more distros should support apt-get, it's a much better tool.

Also, as mentioned before, alien works fairly decent on debian machines for using RPM packages, it would just be a lot easier for everyone if some sort of common ground was found between the different methods of packaging.

Re:Ugh, I hope not

[vidarh]

RPM IS the standard, both defacto by being used by distro's making up the vast majority of Linux distributions, and enshrined as required by Linux Standard Base.

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?

Re:Ugh, I hope not

[krmt]

Debian has a policy that ties everything together. Packagers have to follow this policy, and because it is codified, it leads to a high level of consistency across the distro. That, combined with the vast amount of testing from users of the development branches of Debian, creates the overall illusion that .deb's and apt are far superior to everything else.

It's the Debian project that makes Debian great, not the software itself.

Re:Ugh, I hope not

[EMR]

Well, Fedora has a policy now as well.. Which includes testing phases for packages. (unstable, testing, stable).. And consistency in package naming and dependencies. and Mandrake has similar things as well..

Re:Ugh, I hope not

[stevey]

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

There are two obvious reasons I can think of.

The first is the sheer size of the Debian package repositories. There are more Debian packages available in the "standard" locations than are available for anything else, such as Mandrake or RedHat.

Sure there's nothing stopping you from adding different repositories to download from, but if they're not official changes are they're not signed in the same way, and are less "trustworthy".

The second reason that Debian's packages are so positively regarded is that they are guided by the packaging guidelines, these ensure that the packages all play well together, and mean that you (almost) never lose configuration file changes on upgrade - something that other distributions sometimes seem to suffer from.

I guess most Mandrake/RedHat users don't care, but Debian packages are available across a much wider range of platforms, which is a bonus if you have lots of different machines to look after - you can treat them all the same from the install point of view, something you can't do with other more platform-specific distributions

Re:Ugh, I hope not

[krmt]

Great, so everyone is just reinventing Debian then?

Re:Ugh, I hope not

[StormReaver]

That's all fine, but that isn't what he was asking. He was asking what makes the deb package format supposedly superior to the RPM package format.

Distribution policy, package availability, and the software the manipulates the packages have nothing to do with the package format's superiority or inferiority.

Little-used advantage of RPMs?

[makomk]

One of the things that I find is really great about RPMs is that you can find out what package a file is from using rpm -q -f /path/to/somefile (generic RPM feature, not URPMI-dependant). This is great for tracking down the source and purpose of those mysterious files that you find lying around on most systems. I don't know of a good way of doing this on Windows, which is one of my pet Windows annoyances.

Re:Little-used advantage of RPMs?

[Sunspire]

I seriously couldn't move back to a Windows style "every program installs itself" with files going all over the system to god knows where. I've got something called "uwstart.ini" in my C:\ root. Who put it there? Nobody knows. With a properly packaged Linux distribution these days, every file outside your home directory and temporary files should be accounted for and belong to some package. Every, single, file. In a properly admined system you've got no business going outside your home directory in the first place, unlike Windows.

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:Little-used advantage of RPMs?

[Risto]

I thought I was the only one that thought that Windows, not Linux is in need of better package management, but apparently there is at least one more person out there that understands RPM

Re:Little-used advantage of RPMs?

[TheOrquithVagrant]

Also, lets not forget rpm -V and rpm -Va, which verifies the integrity of the files in installed packages.
I recently managed to mangle my system badly, with filesystem corruption on the root filesystem leading to multiple damaged executables and libraries. I could still recover it without a reinstall, by checking rpm -Va, and looking for md5sum and size mismatches on stuff in binary and library paths, and simply doing apt-get reinstall package on the things with bad files. Quite lovely.

Great news, but y'all will need this...

[Eggplant62]

I'm excited to hear that urpmi is available for Fedora. It will give me renewed reason to install it on one of my machines here and play more with Fedora. I've always had a pet peeve for systems that lacked the kind of package installation software such as apt/get, urpmi, etc. Fedora has finally solved that.

However, to make urpmi truly useful, there needs to be a repository of good source trees for ftp download for the particular distribution. Thus the folks at zarb.org created easyurpmi.org to help folks out in configuring source media on Mandrake. Loaded with lots of different mirrors carrying Mandrake RPMS from the various different sources (main, contrib, updates, plf, etc), this tool generates a commandline that will add a urpmi source media entry to the urpmi database.

Now, someone needs to get on the stick and start compiling the sources for Fedora urpmi sources. Hop to it, kids.

Re:dpkg ! rpm

[RAMMS EIN]

.deb and .rpm do indeed fullfil the same function, and are more or less equally good. This is exactly why I detest RPM. Why did they have to cook up a new and incompatible format, rather than use .deb?

Debian packages don't suffer from the incompatibilities that RPMs do (RPM was changed incompatibly a number of times), and RPM has long lacked the convenience of apt. All this could have been avoided if distros had adopted .deb.

Building from source?

[Glock27]

Which of the Fedora package managers does the best job of building from SRPMs, if any? I like the idea of being able to build my own binaries using my own compile flags for certain packages... What are the issues with using different package managers after the initial install? Will urpmi

Alternatively, is there a distribution point for AMD (32 and 64 bit) optimized RPMs?

TIA...

linux is linux

[deathguppie]

I use both Qcad, and Varicad for my personal drafting. But when my personal distro choice (Gentoo), wasn't supported by Varcad. I just emerged RPM, and installed the Fedora2 RPM. Everything has worked fine. So I tried a couple more. And Guess what?

It seems as long as the dependancies are correct, they just seem to work. Go figure

Re:linux is linux

[skiman1979]

I've installed RH RPMs on Mandrake through both the rpm commandline and through urpmi and they always seemed to work fine. I'll have to try emerging RPM on my gentoo box to see how it works. I never thought to do that before.

URPMI keeps me...

[bob670]

stuck on Mandrake, mostly out of pure laziness. But since I don't care for the way Mandrake hides/alters some default file locations this puts Fedora back on the table for me. Hmmm, choice is good....

Re:URPMI keeps me...

[buchanmilne]

But since I don't care for the way Mandrake hides/alters some default file locations this puts Fedora back on the table for me.

I would really like to know what you mean here. Having used Mandrake, and doing consulting on RHEL2, RHEL3 and Fedora2, I can't think of any differences ...

YaST

[digime]

Anecdotal for sure but: I've been using Mandrake and urpmi for about a year and a half now. I create my own RPMs for programs I install that don't have one, so that I can uninstall it easily if need be and to contribute something back to the community however small. I list all dependencies in the RPM exactly like I should, however urpmi never would automatically resolve those dependencies on another Mandrake box (the box the RPMs were built with of course had the dependents).

I decided to install SUSE last week for s#17s and giggles, and to see why it was so well thought of. YAST amazingly resolved those dependencies in my RPMs without a hiccup. Out of the 100s of packages I've installed I have not been in dependency hell once. I also like the fact that you can right-click on any RPM and click "Install with YAST" in the context menu. Very, very easy and nice. Not one problem so far installing software.

Re:YaST

[buchanmilne]

Anecdotal for sure but: I've been using Mandrake and urpmi for about a year and a half now. I create my own RPMs for programs I install that don't have one, so that I can uninstall it easily if need be and to contribute something back to the community however small. I list all dependencies in the RPM exactly like I should, however urpmi never would automatically resolve those dependencies on another Mandrake box (the box the RPMs were built with of course had the dependents).

If you had urpmi media available that had the required packages, then maybe you didn't update the medium.

I build on all sorts of machines, and install packages via urpmi (from local disk, network, cdrom, or the build cluster via ssh).

Re:YaST

[digime]

If you had urpmi media available that had the required packages, then maybe you didn't update the medium

The update medium on my machines stay updated, and I have the original CDs and PLF in my sources also. Basically there aren't prebuilt packages for Mandrake for some relatively common libraries and programs, either officially or unofficially. That or the name of the package for Mandrake was not the standard name of the library/program.

I'm not putting down urpmi, and YaST would choke if it couldn't find a package just like urpmi does. But, YaST is a vastly superior tool all around. It's comparable to Control Panel in Windows in every way, only better IMO. This, coupled with the fact that SUSE seems to have packages prebuilt for just about everything, make software installation a non-issue. That's saying a lot for a Linux distro as we all know. Windows users are always complaining about a two-click installation. Well, SUSE with YaST is it. I didn't think anything could be easier than Mandrake and urpmi, I was wrong.

Re:YaST

[buchanmilne]

Basically there aren't prebuilt packages for Mandrake for some relatively common libraries and programs, either officially or unofficially.


Well, then, if you have made a package, upload it to incoming, send a mail to cooker, and someone will check it and upload it.

But, in the meantime, change to the directory above the one that holds your RPMS (ie the result of 'rpm --eval %_rpmdir') and run 'genhdlist .', and then run 'urpmi.addmedia myrpms file://`pwd` with hdlist.cz', and you will be able to urpmi them, or urpmi anything that depends on them. And, if you don't want to genhdlist all the time, use a virtual medium instead.

I do this, and I do it on a remote build cluster, and I can urpmi any package I build anywhere.

That or the name of the package for Mandrake was not the standard name of the library/program.

File a bug on the package that has the missing provides (the name can be different, but it should provide the generic name, like openssl-devel).

Re:YaST

[digime]

While I appreciate your advice, I never said I needed help installing RPMs or filing bugs. I have absolutely no problem with either. You're writing to someone that prefers to compile their own source code and compile the dependancies himself.

I think you might be missing the point of my posts, and the point of the story, which was Fedora deciding on urpmi as their new package front end. This, undoubtedly, is to increase user-friendliness. My point is, for the Joe Sixpacks of the world, you can't beat YaST. Also the story asked if this was a step closer to "Cross-distro RPMs". YaST proved (to me) that it could handle some RPMs better than the distro the RPMs were created for.

BTW - YaST was just GPL'd by SUSE (although it's not available for download yet). Try it and you'll see why they hung on to it so long.

Re:YaST

[buchanmilne]

I think you might be missing the point of my posts, and the point of the story, which was Fedora deciding on urpmi as their new package front end.

No, it was just that someone ported urpmi to Fedora, and made packages available, as part of a project to bring some of the really nice features on Mandrake to other RPM-based distros.

YaST proved (to me) that it could handle some RPMs better than the distro the RPMs were created for.

My point is that you must have been doing something *really* wrong, because I have built hundreds of packages on many different machines, installed them on many machines via urpmi or just by double-clicking on the package, which required a number of other packages to be installed, with no problems.

BTW - YaST was just GPL'd by SUSE (although it's not available for download yet). Try it and you'll see why they hung on to it so long.

No thanks, I don't want a config tool that forces you to use it for everything you do, that does nothing more than the tools I already have that allow me to do anything I like manually without clobbering my changes.

Re:YaST

[digime]

My point is that you must have been doing something *really* wrong

Nope, it's just that some packages just aren't available in any of the common repositories. Surely you don't think every program and every library ever written is available for every distro. You've obviously never packaged a program that used anything out of the ordinary. Good for you.

No thanks, I don't want a config tool that forces you to use it for everything you do...clobbering my changes

There you go missing the whole point again. Grandma is not going to be tweaking her config files. My point is urpmi might be nice, but if you're going to give grandma a tool, YaSt is better. We could go on talking about the merits or lack thereof of each forever. You know my opinion. And I'm the one that's more experienced since I've tried and used both, and you refuse to. So I'm done talking. How about we discuss religion or politics. Those issues ought to be settled in about the same amount of time.

Zero Install

[RAMMS EIN]

What I would like to see more in distros is Zero Install.

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.

Re:Zero Install

[IamTheRealMike]

The problem with zero install is that it's not backwards compatible enough. There's no easy way for a zero install app to use the Python on your system but fall back to a zero-install build on the net if that's not present. It can be done but it's really non-trivial. Oh, not to mention that it doesn't fit in with the FDO standards being created for things like menus (not *everyone* wants to use their file manager for that), file associations and so on.

Re:Zero Install

[tal197]

The problem with zero install is that it's not backwards compatible enough. There's no easy way for a zero install app to use the Python on your system but fall back to a zero-install build on the net if that's not present. It can be done but it's really non-trivial.

#!/bin/sh
[ -x `which python` ] && exec python prog.py "$@"
exec 0run "python.org/python 2004-01-01" prog.py "$@"

This runs 'prog.py' using the local version of python if available, or using 0install if not (assuming python was available there).

Default file associations are very easy. Try running ROX-Session through Zero Install, then click on an archive. It will decompress with Archive. Click a text file, and it will open in Edit.

With Zero Install, the desktop provider links *every* association they want by default, and the actual applications are fecthed as needed; no need to intersect the distribution choices with the set of installed packages.

Re:Zero Install

[IamTheRealMike]

Sure, like I said it's possible to use cute hacks in certain circumstances. Now make that automatic for the 40-50 ELF libraries typical modern desktop apps use.

For file associations, I'm talking about "run random 3rd party app, save a file, click the file". How does the desktop know to link that file type to the program just run? Maybe ROX knows, how about KDE and GNOME which are based on the idea of files in magic path locations to describe this?

Re:Zero Install

[tal197]

Sure, like I said it's possible to use cute hacks in certain circumstances. Now make that automatic for the 40-50 ELF libraries typical modern desktop apps use.

Well, you're the linker expert, but can't something like your relaytool do that automatically? Assuming this is the behaviour you want; it doesn't do much harm to always use the zero install version and phase out use of the old libraries, at least for smaller ones like expat. Using local libraries is a small efficiency gain when running on legacy systems; it's not the end of the world if it doesn't work.

For file associations, I'm talking about "run random 3rd party app, save a file, click the file". How does the desktop know to link that file type to the program just run?

Presumably, the application added the association when it was run. If it can do it at install time, it can do it at run time.

Re:Zero Install

[IamTheRealMike]

Well, you're the linker expert, but can't something like your relaytool do that automatically?

relaytool is a useful program to have in our kit, but it's not meant for relaying large numbers of large libraries as is typical with most programs. The relay blocks it generates bloats the working set considerably: while for <100 functions this isn't really a problem once you go beyond that it begins to make an impact.

I think it's possible to use even more advanced linker tricks than relaytool to fix that problem, by allowing MacOS X style library "swallowing" where the swallowed library is sucked into the executable binary itself and used only if the system library is not present, otherwise the highest version takes priority. But, this is still theoretical and would need more R&D which I don't have time to do currently.

I'm also concerned that by going down that route people would end up swallowing loads of libraries which would hugely bloat download times - without a standardised platform to guarantee large chunks of functionality you would end up shipping most of the OS in your binaries.

Using local libraries is a small efficiency gain when running on legacy systems; it's not the end of the world if it doesn't work.

I have to disagree. Duplicating libraries like that instantly doubles memory pressure on a desktop system - our performance due to swap load is already pathetic enough. It doesn't scale as a solution. It might work in an all zero-install distribution but such a system would not bear much resemblence to the Linux systems of today.

Presumably, the application added the association when it was run. If it can do it at install time, it can do it at run time.

That works, though it requires wrapper scripts or patches to all the apps. So does autopackage however, so I guess it's an academic point :)

Re:Zero Install

[tal197]

[ use old /usr/lib if available, for mixed zero-install/traditional systems ]

I think it's possible to use even more advanced linker tricks than relaytool to fix that problem, by allowing MacOS X style library "swallowing" where the swallowed library is sucked into the executable binary itself and used only if the system library is not present, otherwise the highest version takes priority. But, this is still theoretical and would need more R&D which I don't have time to do currently.

Actually, there's a very simple solution for ELF libraries: you can add directories to the library search path in the ELF header.

That is, instead of linking to /uri/0install/gtk.org/libgtk.so, you link to libgtk.so (as usual), and add /uri/0install/gtk.org to the library search path in the header. Presumably you can change the order of the listed directories to decide which version gets used in preference (local or zero install) if both are available.

Re:Zero Install

[IamTheRealMike]

You can do that by modifying the rpath yes, though obviously that solution only works for the zero-install case. Once you start mixing several libraries together in the same image with different (possibly conflicting) rpaths things can get quite confused but it does work.

It also doesn't let you choose between newer/older versions, but I doubt that's often a problem.

The trick then for you is to get zero install bundled by default, have you considered sending it upstream to lkml?

Re:Debian

[skiman1979]

If you want package management to Just Work(TM), use Debian. It comes with apt-get, which automatically downloads and installs your package _and_ its dependencies

Well urpmi on Mandrake will download the package _and_ its dependancies as well. I can set up my system to point to one or more mirrors, as well as the installation CD's. Then when I 'urpmi ' it will search through the FTP mirrors I have configured to find the package and each dependancy (if any). Urmpi will return the list to me asking if it is ok to install these, and the original package. I think it handles this pretty well. I've never used Debian, so I can't say anything about apt, but apt isn't the only thing that does dependancy checking/downloading/installing.

urpmi media and Mandrake upgrades

[kbahey]

When upgrading Mandrake, e.g. from 9.1 to 10.0, make sure you delete the old hdlist.cz and synthesis.* files from the previous release, and use urpmi.addmedia to add the new release media (CD) to your machine.

Here is a list of commands to do that:

# Cleanup
cd /var/lib/urpmi/
rm *

# Insert CD1 in drive
mount /mnt/cdrom

urpmi.addmedia "Mandrake Linux 10.0 Final CD1 (x86)" removable://mnt/cdrom/Mandrake/RPMS
umount /mnt/cdrom

# Insert CD2 in drive
mount /mnt/cdrom

urpmi.addmedia "Mandrake Linux 10.0 Final CD2 (x86)" removable://mnt/cdrom/Mandrake/RPMS2
umount /mnt/cdrom

# Insert CD1 in drive
mount /mnt/cdrom

urpmi.addmedia "Mandrake Linux 10.0 Final CD3 (x86)" removable://mnt/cdrom/Mandrake/RPMS3

After that, you can go ahead and add whatever ftp site you want in addition to what you have.

Doing this will save you a lot of confusion and error messages.

Re:urpmi media and Mandrake upgrades

[violajack]

Or there's my solution:

Using the Software Manger - uncheck all removable media

Add ftp sources for the current release and the cooker.

Change the release # in the updates_source to "current" eg. 9.2 > 10.0 (or just "current", as there is usually a link to the current release on the ftp server.

That should always give you access to the lastest versions of a package, although sometimes there are a lot of dependencies, but I've always had them work.

I haven't actually upgraded to 10.0, but at this point most of my packages are from the official 10.0 release, and some are from the cooker, and the system runs just fine.

Re:Debian

[IamTheRealMike]

I'll keep repeating this until posts about RPM being good/not doing dependencies/both no longer get modded up.

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

This seems wrong

[Cro Magnon]

It's just asking for trouble to have "yum" and "urpmi" on the same system!

Re:This seems wrong

[Sunspire]

Why, they're just frontends to the RPM database? As is apt-get for Fedora. You install something with one and the other will know about it.

Bottom line is however that Fedora comes with only yum and it will continue to do so, and up2date also uses yum in the background. New users will just stick with it, if you're experienced enough to have a different preference you can go and download it youself, or use yum to do it for you in the case of for example apt-get from Fedora Extras.

Re:This seems wrong

[juhaz]

No more than having yum and apt-rpm on the same system.

Doesn't matter how many zillion frontends you have configured if the repositories they use are not incompatible with each other.

Hurray for urpmi

[LibrePensador]

I have tried all of the tools available on rpm-based systems, yast, apt, yum, and urpmi is by far the best.

Why?

*It's dependency handling is superb.

*Urpmi has been honed for a long, long time, longer than apt-for-rpm or yum.

*It makes it dead easy to do parallel installation to a bunch of systems from one master one.

*It is much more efficient than yum. And Yast is a pain if you want to install software from a bunch of external repositories. So long as you stay with what's on the CDs, you are good. Additionally, Suse apt-for-rpm is neither as mature nor does it have the big repositories that Mandrake's urpmi has. I realize that this has to do with the respective size of Mandrake's and Suse's communities. By the same token, it also means, that urpmi has been in wide use for a long time and is very tested.

*It would be great to only have to learn about one way of installing software in all rpms systems.

Apples and oranges

[magefile]

RPMs don't do dependences? Neither do deb files. apt-get is more directly comparable to yum. No, I'm not going to say up2date, as that sucks.

I don't have a response to the amount of packages available, except to say that I created a mini yum-repo on my own box - just a directory that yum knows to access - of everything I couldn't find in a standard repo.

The rest of your post is just Distro Wars, and largely irrelevant. The grandparent didn't say anything about Debian, and you can get apt-get for Fedora.

Big feature of URPMI that APT doesn't have

[kabloom]

URPMI has a big feature that APT doesn't. (At least back when I used Mandrake 8.2)

In APT, you *need* to have the Packages file to know what packages are in your archive.

With URPMI, you don't necessarily need the hdlist file - URPMI can use rpm -qp (even over HTTP!) to find out all of the information it needs to know about the package. It takes longer, but it can be done.

Re:Big feature of URPMI that APT doesn't have

[sirReal.83.]

Do you really want to trust the packages of someone who can't even figure out how to set up their repository correctly, though?

Re:Big feature of URPMI that APT doesn't have

[kabloom]

(A) it would make it easier for me to set up a repository for myself. (B) it would make it easier for me to use urpmi with my distribution's CDs or website, even if the distribution didn't set up their mirrors with urpmi in mind. so there you have two reasons why you might trust someone who didn't set up an hdlist file.

Re:Debian

[RAMMS EIN]

I agree very much that Debian is not ideal. That said, it blows every other distro I have used out of the water. I am the Debian zealot I am because many people complain that something does not work in "Linux", even though it does on Debian.

Your solution, developers packaging for every distribution, is not going to work unless this is made ridiculously easy. I don't think this is ever going to happen. I have tried packaging software for various distros, and I found it to be a complex and laborious process. Automated tools for creating packages for a variety of distros just don't work, because they don't know the right dependencies, file locations, etc, for every distro out there. Also, it takes lots of space on their servers.

I think the current approach (let distributors package software for their distro) is better than what you are proposing. Better yet would be a centralized repository that all distros tapped into, along with separate repositories for distros that want to deviate (e.g. provide customized packages).

The current Debian repositories are not going to work for a scheme as proposed above. Stable is too far behind what most people want to run, and unstable is too volatile. However, Debian's package management tools are entirely adequate. apt gracefully handles multiple repositories.

By the way: Debian does include non-free software, you just have to specify explicitly that you want to use it.

Re:Debian

[Knuckles]

As has been pointed out numeroud times in other replies, every dependency resolver is just as good as a.) the dependency info in the packages b.) the size of the repository.
Debian currently has > 13,000 packages, and no Mandrake of Fedore wil ever top that. That is why apt is so cool

Cross-distro packages is what I need

[ForMeToPoopOn]

Good to have a new tool to install RPM packages on Fedora. The more the merrier.

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 /.ing.

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:Fedora has best packages

[sirReal.83.]

Sure, Fedora supports package managers such as yum, apt, and urpmi. But what really matters is the quantity and quality of packages.

With Debian, we have apt, more packages than any other distro, and a more thorough and sane policy.

Before you decry me as biased, do some research and find out for yourself.

Re:Debian

[IamTheRealMike]

Your solution, developers packaging for every distribution, is not going to work unless this is made ridiculously easy. I don't think this is ever going to happen.

Well, I disagree. I'm working on making it easy. So far it's not doing badly, though for more robust installs we want to be able to delegate to apt/yum/urpmi/whatever when there are no distro-neutral packages available.

I am the Debian zealot I am because many people complain that something does not work in "Linux", even though it does on Debian.

There are plenty of things that work in Fedora/Mandrake/SuSE that don't work (out of the box) in Debian, so I don't really see your point. Every distro has strong points and weak points.

Re:Debian

[skiman1979]

the size of the repository

I'm not sure I agree with this, unless I'm thinking about it differently. We could write an efficient, fast, dependency resolver that only has a package repository of 1,000 packages. As long as all dependancies are included in that repository. Making the repository bigger by adding 10,000 packages to it doesn't necessarily make the resolver any better. It just makes the repository better. The resolver still works the same way. Just like an employee information system that links all information for each of 100 employees versus 10,000 employees. The second one isn't necessarily better than the first. Or am I missing something here?

devel() dependencies

[NED260]

I thought I might plug an other topic I'd worked on, the so called devel() dependencies: http://qa.mandrakesoft.com/twiki/bin/view/Main/Rpm DevelDependencies

In this buildoutput you can see why these devel() dependencies are needed:
http://anorien.csc.warwick.ac.uk/build/i5 86/fedora _urpmi/BO/problem/perl-URPM-0.95-2mdk

As the rpm-devel package on Fedora doesn't Require all the packages that are needed to be able to build something with it.

This is the install log for the package on Fedora:
http://anorien.csc.warwick.ac.uk/build/i5 86/fedora _urpmi/urpmi/perl-URPM-0.96-1mdk

This is the one for Mandrake:
http://anorien.csc.warwick.ac.uk/build/ i586/cooker _main/urpmi/perl-URPM-0.96-1mdk

As you can see, the same BuildRequires on a Mandrake system pulls in all the packages required.

Re:devel() dependencies

[NED260]

Broken link:

http://anorien.csc.warwick.ac.uk/build/i586/fedo ra _urpmi/BO/problem/perl-URPM-0.96-1mdk

I have no idea...

[Kjella]

...WHY they're better, but I've definately had far less problems with .deb packages than .rpm. Between wajig (brilliant extension of apt-get) and .deb packages, I've never been happier. Of course, this could all depend on who is packaging the packages, I have no comparison when it comes to the format. I certainly wouldn't want to replace something that works so well.

Kjella

Package format vs. Package Manager vs. Distros

[hduff]

.rpm vs. .deb vs. .tgz vs. source code

These are the package formats. The first three are attempts to improve things over a source code installation by adding advanced scripting, dependency resolution and post-installation management. (There are other obscure packaging formats.) Each one has strengths and weaknesses and features the others lack. Since it's all open source, why can't the best feature be incorporated into all of them? The answer is that initial design considerations preclude easily adding ceratin features (similar the old GTK find file dialog problem).

apt vs. yum vs. urpmi vs. yast

All accomplish about the same thing which is to easily install software packages using dependency resolution. Each was written to scratch a particular itch. apt used for rpms (originall written for .deb packages) is considered kind of a hack, especially the way it eventually installs the packages. yum was written to provide apt-like features, but written in pyhton, like all of Red Hat's tools, so it could more easily integrate into those tools. urpmi is written in perl since Mandrake's tools are written in perl (as is Mandrake's disk partitioning tool, which might be why Red Hat hasn't integrated it into Anaconda). I'm not sure what apt and the package management portion of yast are written in, but the same difficulties might apply to them.

Debian vs. Mandrake vs. RedHat/Fedora & clones vs. SuSe vs. Slackware vs. etc.

While all the distros are Linux, each uses a modified version of the kernel (and glibc?) to tweak it's performace/feature set and show that it's version is superior. That, along with slightly different file locations, variations on a few configuration file names, and differnt vesions of core libraries and utilities just make it more difficult to create "universal" software packages. Getting these distros to eliminate this kind of incompatability is likely impossible because it removes their perceived "competitive advantage" and fails to massage their respective engineers' often siezable egos.

Solving the Problem

There is some work afoot to cooperatively meet on a common hdlist format so that all the versions of the package managers can use a single index file (repositories only need generate a single file to be apt-yum-urpmi-yast-etc compatible. That's a good thing and allows customization of the management tools for particluar needs (like different editors using the same text file formats).

The package incompatability problem could be ameliorated if packagers would statically compile binaries. I know, that uses more "space" and introduces potental security threats, but there are ways to deal with that: cheap and huge hard drives solve one problem and key signing, md5 and similar technologies address the other.

Put Religious Wars and Ego Aside: Work Cooperatively

There's not a need for a single, unified packaging tool or packaging format just like there is no need for a single, unified desktop environment. There are some areas where everyone needs to cooperate more effectively, though.

Both urpmi and yum support gpg checking

[Sits]

It is not really RPMs job to enforce security, it is up to the dependcy manager and both yum and urpmi can be set to do this since those are going to be the things installing stuff automatically.

In yum.conf add gpgcheck=1 and it will check that the GPG signature.

urpmi is set to check signatures by default and normally a repository will tell you what sigs its RPMs are signed with when you add it.

Re:dpkg ! rpm

[ultrabot]

.deb and .rpm do indeed fullfil the same function, and are more or less equally good. This is exactly why I detest RPM. Why did they have to cook up a new and incompatible format, rather than use .deb?

Why don't you detest Debian instead for sticking to a format that is not the "standard" as specified by LSB, esp. if there are no real technical reasons? Why not go for a format that is being backed by hard corporate money?

Re:dpkg ! rpm

[shaitand]

"RPM has long lacked the convenience of apt"

In what world is that? There is apt for rpm my friend and some HUGE repositories out there.

Yes apt is good and wonderful, deb is equal, so why not drop deb like the rest of the distros out there and keep apt?

Right now debian is not standards compliant, like the parent said rpm is specified in the LSB. This fight was fought and settled long ago... debian just won't listen.

Re: and in apt/dpkg...

[chrwei]

dpkg can do this too (the dpkg command is to apt/.deb what the rpm command is to urpmi/.rpm)

dpkg -S /path/to/some/file

One thing I like better about apt/.deb/dpkg is its ability to run an interactive script pre/post install to help the admin setup whatever is being installed.

one thing I like better about urpmi is that if the package has a config file that differs from what's currently install it offers to show you the diffs and gives the option of using the new one and keeping the old as foo.rpmold, using the old and keeping the new as foo.rpmnew, or just discarding the new. 95% of the time I discard the new, but it's occationaly been usefull to have the other options.

No, we still don't have cross-distro rpms

[shaitand]

Unfortunately mandrake has chosen to rename their core system packages and libraries in such a fashion that a redhat rpm won't recognize them as dependencies and vice versa.

Do they gain anything by this? NO Did it involve lots of work with absolutely no gain whatsoever to go from standard redhat naming to the Mandrake scheme? Yes.

why? So they could claim they were their own distro and not just a redhat knockoff with their own logos and some graphical configuration utils.

Pretty much the same reason they use their own installer which is inferior to redhat's. And their own hardware detection, which again, is inferior to redhats.

Re:No, we still don't have cross-distro rpms

[buchanmilne]

Unfortunately mandrake has chosen to rename their core system packages and libraries in such a fashion that a redhat rpm won't recognize them as dependencies and vice versa.

While we may have renamed them to have saner library handling, there are provides in the packages to keep them compatible with the broken RH names. If you find one where this is not the case, feel free to submit a bug report.

I won't bother with the rest of your FUD.

This problem goes deeper

[Stevyn]

This is the problem I see with getting people to try linux. People recommend Suse, Mandrake, or Fedora to newbies because it's easy to set up and use. But once they want to update or install a program not offered by those companies in a nice package it becomes a pain. I'll take mandrake 10 as an example. I can not update kde by using something like apt or portage. Last night I upgraded from KDE 3.2.2 to 3.2.3 (yeah I know, why?). To do this I had to uninstall all the packages that had to do with kde, restart X into icewm, and install all of the new binaries. Now mandrake doesn't offer binaries of kde 3.2.3. Luckily I got them from richardlinux.net who offeres URPMI access so I can still use mandrake's URPMI. It took a few attempts of removing all the old packages to take care of the conflicts. I eventually got it, but I still have to reinstall things like xine and some others.

Now on gentoo or debian, it would have been a simple command to type. It would take a while to compile, but I could just let that sit overnight and throughout my day at work and come home to kde 3.2.3 all set up.

Where am I going with this?

The distros that are usually thought to be more difficult to install are debian and gentoo, however their packaging system is great. However the distros that are easy and quick to set up have bad or outdated or very incomplete packaging systems (mandrake) and so you can't use them.

I've been using linux exclusively now for a few
months. I put gentoo on an older system to get a feel for it and it's not that hard to set up. I intend to put gentoo on the computer with mandrake mostly because of their easier packaging system.

It's just ironic that the easy distros are a pain once you get them going and the hard distros are easy once you get them going. It's a double edge sword. I hope these anoying rpm based distros will get together and either create a standard packaging system or just duplicate apt or portage.

Re:This problem goes deeper

[MobyTurbo]

Now on gentoo or debian, it would have been a simple command to type. It would take a while to compile, but I could just let that sit overnight

Um, Debian doesn't compile with the "apt-get install" command. It uses binary .deb packages, which are similar in nature to rpms. Though it is possible, but much more involved, to compile packages too; but Debian users rarely do that.

Re:dpkg ! rpm

[RAMMS EIN]

Last I checked, the format specified by LSB was incompatible with the format used by Red Hat (and probably others). This sort of incompatibility doesn't plague .deb.

Also, as far as I know, .deb was there first. Therefore, it's RPM that's incompatible. At any rate, .deb has had apt longer, whereas the RPM distros have had various other implementations of the same idea, with varying success.

All I know is that package management works great on Debian, and on RPM based distros I always run into trouble after some time.

how is it any worse than....

[robochan]

Doubleclick exe/msi installer
Click "Next" to continue
Accept 27 page EULA
Click "Next" to continue
Confirm "install type", full/minimal/custom
Click "Next" to continue
Confirm/alter install path
Click "Next" to continue
Do you want a program group created? y/n
Click "Next" to continue
Watch progress bar...
Click "Next" to continue
Do you want to read the README.txt now? y/n
Click "Next" to continue
Do you want to create a desktop shortcut? y/n
Click "Next" to continue
Do you want to run the internet updater? y/n
If Y, click "Next" to continue to repeat previous instructions, if N, then click "Next" to continue
$PROGRAM has been installed to $PATHBLAHBLAH, please register, would you like to do so now? y/n
Click "Next" to continue
Installation complete, Click "Exit" to finish
You must reboot for changes to take effect, do you want to reboot now? Reboot/Cancel

Re:how is it any worse than....

[number]

Wow, so all you have to do is type 3 little commands in Linux and it reads your mind to decide any configuration settings, thus being more convenient than your (elongated) windows example?

Does this mean...

[jonadab]

Does this mean that rpmdrake will also be coming to Fedora?

Mandrake had (package installation tools) first

[buchanmilne]

Fedora/RH now has the posibility of running Yum, Apt-Get, URMPI.

Which Mandrake has had for a few years now. Both apt (and synaptic) and yum are in contrib (and have been for a while).

Anyway, Mandrake has more packages ...

Re:Fedora has best packages

[buchanmilne]

But what really matters is the quantity and quality of packages.

With Debian, we have apt, more packages than any other distro, and a more thorough and sane policy.


With Mandrake, we have urpmi, apt, yum, policies, more tools to automatically assist in generating quality packages, more tools to check packages for adhering to policies, and we're rapidly catching up.

Plus, we have a working GUI installer ;-).

Do some reasearch and find out for yourself

URPMI

[c0d3h4x0r]

What the hell is URPMI?

Re:URPMI

[buchanmilne]

What is google?

http://www.google.com/search?hl=en&ie=UTF-8&oe=U TF -8&q=urpmi

Re:URPMI

[c0d3h4x0r]

You entirely missed my point. Slashdot articles should always take a few words to explain what the things are that each article references, rather than assuming that everyone already knows and making us have to look it up.

Re:Debian

[mufasio]

I'm not sure I agree with this, unless I'm thinking about it differently. We could write an efficient, fast, dependency resolver that only has a package repository of 1,000 packages. As long as all dependancies are included in that repository. Making the repository bigger by adding 10,000 packages to it doesn't necessarily make the resolver any better. It just makes the repository better. The resolver still works the same way. Just like an employee information system that links all information for each of 100 employees versus 10,000 employees. The second one isn't necessarily better than the first. Or am I missing something here?

I think what he is refering to is that with debian almost any package that you want to run is available in its repository, whereas with mandrake and fedora, etc. If a package isn't in the repository then you have to use a 3rd party repository (which you have to decide for yourself if you trust it or now) or compile it from source. Now this still happens occasionally with debian, but not near as often as it does with other distros. urpmi may be just as good as apt-get but mandrake will never be as good as debian because of the large repository that debian has. Unfortunately, debian isn't as easy to install and use as mandrake and fedora are but it is getting better with the new installer. However, mandrake and fedora will continue to have their niche in the new user market and debian will have its niche in the more experienced user or at least more persistent new user market.

Yes, we DO have cross-distro RPMs...

[WebCowboy]

...it is part of the Linux Standard Base and other standards of the Free Standards Group. The problem is that the standards have not been widely adopted enough. Perhaps that will change over time, particularly once LSB 2.0 is released in its final form. Presently, a few distros (Mandrake for one) are already LSB compliant and should properly install LSB-compliant RPMs regardless of the source. The drawback is that this compatibility is generally "bolted on" by installing--you guessed it--a distro-specific RPM.

RPM has been selected as the standard packaging format for LSB, and as the standard has evolved cross-distribution issues have been addressed. This had always included advocating adherance to the Filesystem Hiearchy Standard (FHS) and now includes things such as a universal package naming standard and standard implementation of printing systems. Those are among the most notorious of cross-distro difficulties we have to contend with right now.

Whatever you think of the RPM format, it serves its purpose quite well, and it is a standard. If Fedora and Mandrake and others start to work together on interoperable solutions to managing RPMs in combination with increasing support for LSB then it would mean a huge advancement in the effort to bring about widespread Linux adoption.

Re:Debian

[skiman1979]

I completely understand that. There are more packages available under Debian than Mandrake or Fedora. I'm a Gentoo user myself, so everything is compiled from source. (That's quite daring of me since I'm on dialup...) :-P

KDE is an exception

[buchanmilne]

The problem is that updating a whole desktop is not really feasible, as there could be some issues with applications breaking, or conflicts which haven't been fully tested (but are before the next release). For example, one of the Mandrake contributors made GNOME2.6 packages available for Mandrake 10.0, but then you had to live with wxWindows (and bittorrent-gui) not working.

However, you will find there are lots of updated packages for Mandrake 10.0, some available via the MandrakeClub, some available on the public mirrors.

Anyway, you may rather ask yourself why a newbie user would want to upgrade from kde-3.2.2 to 3.2.3 (and "because I wanted the latest" doesn't count).

Mandrake project

[buchanmilne]

Some mandrake contributors are already looking at this - but the problem is knowing which SRPM will provide which "provides", and thus knowing which package to build.

But, there are some other more important things to do right now - this will most likely have to wait until after 10.1 (we have enough other features to implement).

Re:dpkg ! rpm

[swv3752]

dpkg and RPM were developed about the same time. Caldera and RH and I beleive SuSE got together to develop RPM. There are many reasons for LSB to standardize on RPM, but what it comes down to is that RPM has more functionality. dpkg is pretty sucky without apt. As apt does work with RPM as well as dpkg, it is not a consideration on comparing the values of dpkg and RPM. Also, at the time, there was no more expectation that Debian was going to last as any other hobbyist distro. I mean Yggdrasil was last published in 1995, right around the time that dpkg and RPM was created.

If an RPM file mets all the dependancies, it can be installed with a newer version of RPM. One can not install a newer RPM file with old version of RPM, but so what. You will probably have other dependancy issues as well- GCC, glibc, etc.

What does URPMI have to do with cross-distro RPMs?

[trashme]

From the story summary:

Are we one step further towards Cross-distro RPMS?

URPMI is just a front-end for fetching RPMS + dependencies and running rpm to install them. yum or apt can perform the exact same function as URPMI. A cross-ditro RPM can just as easily be installed with any of these package managers.

Re:Fedora has best packages

[tordia]

Plus, we have a working GUI installer ;-).

You mean like synaptic or gnome-apt?

URPMI and the PLF

[phreak03]

The PLF or "penguin liberation Front" urpmi repository, provides all the nice things on linux, that potentialy violate the GPL or mandrakes policies for its mirrors (p2p programs, games, ports of old stuff, Return to castle wolfenstien, Codecs, mplayer)

Its nice being about to go "urpmi mplayer" and get mplayer working!
or urpmi et and get emenemy territory working :)

Re:Fedora has best packages

[buchanmilne]

You mean like synaptic or gnome-apt?

No, not a package installation GUI, one for installing the OS ...

Re: and in apt/dpkg...

[chgros]

one thing I like better about urpmi is that if the package has a config file that differs from what's currently install it offers to show you the diffs and gives the option of using the new one and keeping the old as foo.rpmold, using the old and keeping the new as foo.rpmnew, or just discarding the new
Apt offers to:

• diff
• Keep old
• Keep new
• Background process

Re:OT - Meteor

[FauxPasIII]

> Is the MM-20 less laggy than the MM-10? The CPU throttling & slow HDD sometimes makes me crazy.

It's quite a bit faster in terms of raw CPU torque, yes. HDD is not appreciably faster. But, it's got the best currently available chipset for 54mbps wireless under Linux. =)

If you want a huge leap in speed, without a great deal more mass, get a Raven. That's what I use. =)

Re:Debian

[checkup21]

this discussion is getting soooo boring. first of all. When talking about software installation in linux. I exclude all distributions that do not have a built-in default packaging system with huge online repositories. reason is simple. Without this system you never get the job done. Wether you want to install "stable" software, or install new software, or want to install dev packages for compiling software, there is no way to get the job done without these systems. So two distributions drop. Suse, fedora -> bye bye. Even if they do have uprmi now. It doesn't mean someones gonna take care about the server side, which means fewer people will install it, which means fewer people take care on the server side.....this will never change if a distro does not make it mandatory. and i can hear the people saying "but you may do this and that". i will tell you something. Visit your suse or fedora neighbour and look how he is handling his software. You can see his blinking eyes when ne suse boxes show up.... this is reality, not some sort of theory-discussion. Now to the terribly broken packages in debian and co. I had a problem last week. My Lotus notes didn't work because i was using a bleeding edge version of wine. so ? I took the version from the stable repos and my problems where solved (mandrake here). I don't get the problem here. You say there are (in your opinion) terribly broken Packages which makes your point refusing _any_ packaging system ? ok, i had to look for "libwine" and "wine". And nobody's gonna tell you you need both if you don't know yourself. This is a flaw. Yes. But for gods sake, it's no reason to fall back into manually installation (as in suse). And in fact it is not that bad as you describe it. Most of the packages i came accross where packaged quite ok. And the two or three not so ok, does not make urpmi and/or apt way ahead of even windows software installation. marco

Re:Hah, can't fool us!

[Arial Sharon, 10pt.]

you just know it rocks to compile Xfce from source every other week

Dude, everyone knows that Gentoo fans only use Fluxbox.

Re:Wrong

[buchanmilne]

But, yum was *included* in the ditribution (or contribs, which is close enough) before RH hijecked the Fedora project and adopted yum.

And, Mandrake adopted apt quite early on as well.

So, no, I don't think I am wrong, since in January 2003 we had them all in contribs (ie part of the distro).