Please, Yum Yum!

Posted Jul 9, 2006 17:40 UTC (Sun) by warmcat1 (guest, #31975)
In reply to: Please, Yum Yum! by fergal
Parent article: Interview: Jim Gettys (Part II)

> 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
> where you think yum is superior.

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 (guest, #602) [Link] (1 responses)

> 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
> precooked-database-file-from-the-repo way, but I don't actually know it.

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

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
> refetch the entire database for tha repo.
> I'm not so sure about yum.

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
> difference but it seems more likely that this is
> a debian vs fedora filesystem layout difference.

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
glibc-2.3.4-i686
glibc-common-2.3.4-x86_64
glibc-2.3.4-x86_64
glibc-kernheaders-2.4-x86_64
glibc-devel-2.3.4-x86_64
glibc-headers-2.3.4-x86_64

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.