Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


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

URPMI For Fedora Core 2 246

Posted by Hemos from the cross-platform-grail dept.
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 More

URPMI For Fedora Core 2

Comments Filter:

  • apt (Score:2, Insightful)

    by selfabuse ( 681350 )
    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 does depndancy resolution (Score:5, Informative)

      by brunes69 ( 86786 ) <slashdot@nOSpam.keirstead.org> on Monday July 12, 2004 @08:36AM (#9673926)

      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.

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

    • Re:apt (Score:2, Insightful)

      by 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 (Score:2, Insightful)

      by senzafine ( 630873 )
      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.
    • 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.
      • 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.
        • .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.
          • .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?
          • "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:apt (Score:5, Informative)

      by rsd ( 194962 ) on Monday July 12, 2004 @09:32AM (#9674482) Homepage
      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 (Score:2, Interesting)

        by NED260 ( 14091 )
        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 nee

  • urpmi vs yum (Score:5, Insightful)

    by ultrabot ( 200914 ) on Monday July 12, 2004 @08: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:urpmi vs yum (Score:5, Informative)

      by Eggplant62 ( 120514 ) on Monday July 12, 2004 @08:50AM (#9674079)
      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 (Score:5, Interesting)

      by buchanmilne ( 258619 ) on Monday July 12, 2004 @08:51AM (#9674082) Homepage
      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.
      • 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.
    • 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 (Score:4, Informative)

    by alexbartok ( 764756 ) <alex@NospAM.moocows.org> on Monday July 12, 2004 @08:37AM (#9673939)
    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 (Score:5, Funny)

      by Otter ( 3800 ) on Monday July 12, 2004 @09:08AM (#9674229) Journal
      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...

  • 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! (Score:5, Funny)

      by ultrabot ( 200914 ) on Monday July 12, 2004 @08:55AM (#9674120)
      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. (Score:5, Interesting)

    by haeger ( 85819 ) on Monday July 12, 2004 @08:41AM (#9673979)
    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. (Score:3, Informative)

      by FauxPasIII ( 75900 )
      > Whammo, instant mandrake/suse/redhat/fedora. =)

      Usermode Linux will get you an even more complete experience. This is what we use at emperor linux [emperorlinux.com]
      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.
  • *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.
    • 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 som
    • 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.
      • 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 R

  • RPM Lacks Security Checks (Score:4, Interesting)

    by Tocano33 ( 469225 ) on Monday July 12, 2004 @08:48AM (#9674065)
    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 (Score:5, Informative)

      by buchanmilne ( 258619 ) on Monday July 12, 2004 @08:54AM (#9674116) Homepage
      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.
    • 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.

    • 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 f

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

  • The difference is GUI (Score:3, Interesting)

    by levell ( 538346 ) on Monday July 12, 2004 @08:54AM (#9674115) Homepage
    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 [cobind.com] but I can't seem to get it to work right for me on FC2 using a proxy. (Apt has the synaptic GUI).

  • Yay, more out of sync updaters (Score:4, Insightful)

    by Anonymous Coward on Monday July 12, 2004 @08: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.

  • Different Issues (Score:4, Interesting)

    by InodoroPereyra ( 514794 ) on Monday July 12, 2004 @09:03AM (#9674188)
    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.

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

  • Great news, but y'all will need this... (Score:3, Informative)

    by Eggplant62 ( 120514 ) on Monday July 12, 2004 @09:12AM (#9674270)
    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 [zarb.org] created easyurpmi.org [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.
  • 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...

  • Zero Install (Score:3, Interesting)

    by RAMMS+EIN ( 578166 ) on Monday July 12, 2004 @09:32AM (#9674479) Homepage Journal
    What I would like to see more in distros is Zero Install [sourceforge.net].

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

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

          • 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

            • 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

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

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

  • urpmi media and Mandrake upgrades (Score:3, Informative)

    by kbahey ( 102895 ) on Monday July 12, 2004 @09:59AM (#9674767) Homepage

    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.

  • It's just asking for trouble to have "yum" and "urpmi" on the same system!
    • 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.
  • 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. Addit
  • 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

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close