Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
Package ManagerPackage ManagerPosted Jul 5, 2006 11:04 UTC (Wed) by warmcat1 (guest, #31975)Parent article: Interview: Jim Gettys (Part II)
I sure hope they end up with RPM and yum Fedora style. Because even the Maemo/770 "single image" upgrade stuff has a package manager in it to allow third-party apps to integrate sensibly.
Once there have been a few versions of the core packages out there for a while it won't be a given that a binary package will work on a particular platform, it's important to manage that with well-tested and capable packaging techniques. Yum makes a lot of that go away before it even causes trouble by reaching out for a current version of whatever is being installed in the first place rather than leaving the user to go get ahold of a single random RPM from a website somewhere and then run around trying to find deps and hopelessly run up against the fact the binary RPM was build againt core libs that are too old to be on his box.
I guess the concern is the overhead of running the RPM database, it is quite possible to make an "RPM lite" which does not maintain a database, but instead stores installed package *headers* (only) down /var/lib/rpm. RPM can be made to walk the headers in place of having a database. I implemented this technique with busybox RPM for a product here and although it doesn't scale well to hundreds of packages it works great even on a slow ARM for dozens.
(Log in to post comments)
Package Manager Posted Jul 5, 2006 15:25 UTC (Wed) by brugolsky (subscriber, #28) [Link] IMHO, RPM (and dpkg) have outlived their usefulness. Max Spevack, chairman of the Fedora Board, said in this interview that he is interested in shifting the Fedora Project from RPM to a distributed version control system -- i.e., Conary, or something like it. Conary offers all of the benefits of distributed version control, including simple incremental updates via compressed deltas, separation and unification of policy (pre/post-install scripts and triggers) from the software artefacts themselves, as well as a packaging model that utilizes inheritance to relentlessly factor the software build process. It will be a lot of work to convert RPM spec files to Conary recipes, but worth the effort.
Package Manager Posted Jul 5, 2006 20:24 UTC (Wed) by warmcat1 (guest, #31975) [Link] Thanks for the information... there's a link in the interview to this overview of Conary:
http://www.linux.com/article.pl?sid=06/03/30/210216
I don't know that the existing packaging technologies have generally "outlived their usefulness", because for my little set of usage cases (including embedded) RPM is really nice. On a RHEL sort of view I can see that some of the Conary things would be interesting, and in turn that makes it interesting for Fedora, so maybe it will come to pass.
For the OLPC, if the sticking point with having a packaging system at all is the storage footprint, it seems from the descriptions of Conary that problem is getting bigger not smaller in that direction. So it continues to seem to me RPM or some RPM-lite would be a good thing there.
Package Manager Posted Jul 5, 2006 20:54 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Looks like Max Spevack did not say that.
https://www.redhat.com/archives/fedora-marketing-list/200...
Package Manager Posted Jul 5, 2006 22:45 UTC (Wed) by brugolsky (subscriber, #28) [Link] Well that's unfortunate; I had smiled broadly when I read the Newsforge story. Thanks for setting the facts straight. I wish I had the time to go through Core/Extras/RPMforge, etc., and figure out how much effort is really required to switch packaging systems.
Please, not YUM Posted Jul 8, 2006 11:31 UTC (Sat) by fergal (subscriber, #602) [Link] I got so fed up with YUM's slowness and a couple of outstanding bugs that I tried Ubuntu and I'll never go back. apt-get beats the crap out YUM in every way.
I've yet to form a strong opinion on .deb versus .rpm.
Please, Yum Yum! Posted Jul 9, 2006 7:43 UTC (Sun) by warmcat1 (guest, #31975) [Link] Well we all have to use the opinions we arrived at from our experiences. However I have used apt-get on Debian, and used the ported RPM-aware apt-get, and in my experience yum is superior. Apt-get was and is a great boost out of package hell, wandering around in the desert looking for deps by hand, but yum does that job and more. For example, try "yum search" and "yum whatprovides" for an entire metarepo view of what rpm can only provide on installed packages.
On the slowness yum has a system at the moment where it wanders around randomly between its list of mirrors, guaranteeing suboptimal performance for everyone. Recent yum has an sqllite backend and is not in itself slow, but the default mirror behaviours make it seem slow simply because it randomly tries to grab packages from some overloaded server halfway around the world. You can edit /etc/yum.repos.d/* to get yum to use a single local mirror instead of the list and things are very fast on a decent box.
"Your mileage did vary" ;-) but there is my experience.
Please, Yum Yum! Posted Jul 9, 2006 17:22 UTC (Sun) by fergal (subscriber, #602) [Link] apt has all that meta repo goodness too, search, provides etc (apt-cache is the tool for that, not apt-get which might be why you thought it didn't).
As for speed, I did modify my repos and I hit the same mirror site for both fedora and ubuntu. The major difference is that yum hits the repo more often than apt. It also spends an inordinate amount of time loading the repo data (possibly fixed by sqllite).
When I install something with apt-get, all it does is download that package and it's deps, it doesn't do all the other stuff that yum seems to and most importantly it doesn't barf just because 1 repository is temporarily down! The number of times I've had to comment and uncomment Dag Weier's repo is just silly.
There's also the ridiculous behaviour on ctrl-c (switch to next repository, not quit, no that requires ctrl-\ or fishing around for a PID to kill). This is a feature say the developers.
Yum is probably on it's way to being as good as apt-* but I just don't see the point in suffering while it gets there and by the time it arrives, apt will have moved a bit further.
I'd be interested to hear an specific example where you think yum is superior.
Please, Yum Yum! Posted Jul 9, 2006 17:40 UTC (Sun) by warmcat1 (guest, #31975) [Link] > apt-cache is the tool for that, not apt-get which> might be why you thought it didn't
Yes I never saw these capabilities anywhere before yum.
> yum hits the repo more often than apt
The extent of my knowledge about how it works is that it uses HTTP byte ranges to get RPM package headers that contain everything about the RPM except the cpio payload. If it identifies that a package needs to be downloaded, for example, it will go download the header part of that package and then look in there for dependencies. That looks casually like a lot of back and forth, but it allows cool features like arbitrary mixing and matching with localinstall (install this random RPM I already have, getting deps remotely from anywhere you can) local RPMs, multiple repos and so on. I got the impression apt worked on a more precooked-database-file-from-the-repo way, but I don't actually know it.
> ^C
Yes everyone finds that annoying I am sure
> I'd be interested to hear an specific example
Yum does multiarch/multilib (eg, x86_64 mixing/duping i386 libs) in a good way, I believe apt is unable to do this. Although if my belief is wrong, since it came from a discussion on Fedora-list wrt the RPM port of apt, please do disabuse me of it.
Please, Yum Yum! Posted Jul 9, 2006 17:53 UTC (Sun) by fergal (subscriber, #602) [Link] > allows cool features like arbitrary mixing and matching with localinstall> (install this random RPM I already have, getting deps remotely from > anywhere you can) local RPMs, multiple repos
apt does this just fine.
> I got the impression apt worked on a more
I'm not so sure, the effect is the same anyway, all the useful repo data is vailable locally. Adding a new package does not cause apt to refetch the entire database for tha repo. I'm not so sure about yum.
> Yum does multiarch/multilib (eg, x86_64 mixing/duping i386 libs) in a
I don't know for sure but neither yum nor apt should know anything about 32 vs 64 bit. There might be some support in rpm or dpkg for a difference but it seems more likely that this is a debian vs fedora filesystem layout difference.
Please, Yum Yum! Posted Jul 9, 2006 18:08 UTC (Sun) by warmcat1 (guest, #31975) [Link] > apt does this just fine.
Oh well, more props to apt then.
> Adding a new package does not cause apt to
I believe the database part of the repo is lighter in the Yum way of doing things, since it goes to the actual packages to get the full metadata.
> There might be some support in rpm or dpkg for a
Yes, the RPM libs know about multiarch and deal with it, but yum has to be aware of what is going on. For example:
# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{ARCH}\n" | grep glibc
There are two packages called "glibc" of the same version installed in the one box, for example... yum or whatever has to be aware that only the one matching the arch of a new package is a resolution for it, that the -devel package only matches the package with the same arch, etc. Put another way you can have the x86_64 set of libs needed by a package, but if that package is coming in as i686 it is NOT a resolution. Thinking about it the complaints I heard were probably specific to the RPM port of apt and may not say anything about apt's native multiarch powers.
|
|||||||||||