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

[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]

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

[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

[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)

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.

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

[kabloom]

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

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

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

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

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

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.

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.

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

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

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.

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

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.

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

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:Who needs em?

[ultrabot]

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

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

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.

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

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

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

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

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

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.

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

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