Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Red Hat Software Software Businesses Linux

URPMI For Fedora Core 2 246

Jaroslaw Zachwieja writes "Stefan van der Eijk, the autor of Slbd - automated tool to rebuild distributions to different architectures/processors in a sanitized environment, has published set of RPMS of URPMI for Fedora Core 2. The only usage difference is that it uses hdlist instead of compressed hdlist.cz known from Mandrake. Are we one step further towards Cross-distro RPMS?"
This discussion has been archived. No new comments can be posted.

URPMI For Fedora Core 2

Comments Filter:
  • apt (Score:2, Insightful)

    by selfabuse ( 681350 ) on Monday July 12, 2004 @09:35AM (#9673916)
    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)
  • urpmi vs yum (Score:5, Insightful)

    by ultrabot ( 200914 ) on Monday July 12, 2004 @09:36AM (#9673927)
    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:apt (Score:2, Insightful)

    by Anonymous Coward on Monday July 12, 2004 @09:37AM (#9673933)
    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 (Score:2, Insightful)

    by senzafine ( 630873 ) on Monday July 12, 2004 @09:38AM (#9673943) Homepage
    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:Who needs em? (Score:5, Insightful)

    by ultrabot ( 200914 ) on Monday July 12, 2004 @09:38AM (#9673948)

    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? (Score:5, Insightful)

    by Gorath99 ( 746654 ) on Monday July 12, 2004 @09:39AM (#9673956)
    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.

  • by Anonymous Coward on Monday July 12, 2004 @09:55AM (#9674124)
    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:Who needs em? (Score:5, Insightful)

    by RAMMS+EIN ( 578166 ) on Monday July 12, 2004 @09:57AM (#9674133) Homepage Journal
    ``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? (Score:4, Insightful)

    by BenjyD ( 316700 ) on Monday July 12, 2004 @09:59AM (#9674154)
    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? (Score:3, Insightful)

    by ultrabot ( 200914 ) on Monday July 12, 2004 @10:06AM (#9674218)
    Oh. As if that's not easy with urpmi??

    Comparison was with configure/make/make install, not urpmi.
  • by levell ( 538346 ) on Monday July 12, 2004 @10:19AM (#9674333) Homepage
    You can't install new packages with up2date, it just updates the current ones.
  • Re:Who needs em? (Score:3, Insightful)

    by Kick the Donkey ( 681009 ) <kickthedonkey@@@gmail...com> on Monday July 12, 2004 @10:55AM (#9674723) Homepage Journal
    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 [freedesktop.org] entries [freedesktop.org] (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:Debian (Score:5, Insightful)

    by IamTheRealMike ( 537420 ) on Monday July 12, 2004 @11:00AM (#9674773)
    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

  • by buchanmilne ( 258619 ) on Monday July 12, 2004 @01:25PM (#9676537) Homepage
    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:YaST (Score:3, Insightful)

    by buchanmilne ( 258619 ) on Tuesday July 13, 2004 @09:55AM (#9685542) Homepage
    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).

"If anything can go wrong, it will." -- Edsel Murphy

Working...