seth vidal wrote:
On Sun, 2006-09-03 at 10:35 +0100, Andy Green wrote:
Thanks for your post Seth.
On a related issue, I learned last week about rpmcache and what was apparently the old style of repo content distribution based around detached RPM headers into a separate RPM database. Can anyone gifted with the Redhat/Fedora instrutional memory of the time (Seth?) summarize what drove the migration to a completely separate XML metadata database system? The old way sounds more economic with data and code from what I understand of it.1. there was no concept of old-style repositories - that's just revisionist history
No revision intended... I was thinking about a generic "repository" of all the packages in a distro version, along the lines of what the old up2date must have had.
2. there was no concept of multiple repositories with rpm -aid and rpmcache. Apt and yum were the first two tools to give multiple repository support for rpm-based systems.
Fair enough. From what I understood though, one could consider to throw any amount of headers from anywhere into an RPM "database of the possible" separate from the default RPM database, so the concept itself doesn't seem to deny having multiple active repos. Of course it wouldn't go get things for you like yum does as it stood, but I am just thinking about the management of the database using what one can say is a native rpm format.
3. while rpm -aid/rpmcache _might_ have worked for depresolution (we have almost zero evidence of it working in anything, let alone on a large scale) for doing any sort of other querying it was much, much heavier.
Since it would be reusing the librpm stuff that already has a sharp idea of what Requires are missing if you attempt an install, I can imagine librpm at least has most of the tools lying around to do it in a good way using its native database.
4. Trundling around the full rpm header blob is much heavier than just the important metadata. This is why we moved away from compressed headers from yum 1.X and 2.0 days into the xml metadata.
Well I see that yum does want to go get the headers still and I guess parse them
---> Downloading header for java-1.4.2-gcj-compat to pack into transaction set.
java-1.4.2-gcj-compat-1.4 100% |=========================| 26 kB 00:00 and the headers come in again with the actual package.In terms of the relative cost of metadata management from the downloading point of view, it seems that a new compressed XML file is needed every time the repo was updated, whereas a purely RPM header-based system would just be pulling changed headers.
5. the depresolution mechanism was just not as flexible or easily corrected as the ones written in other tools. While the rpm-developers kept threatening to write a depresolver to "put us all out of business" (yes, actual quote) it never materialized. So, rather than wait for something to happen that we had no reason to believe would and rely on a structure we didn't have much influence over we decided to do something ourselves.
Fair enough, I am certainly glad something as useful and reliable as yum does have the advantage of existing. My thoughts are in smaller footprint machines, from my vantage point one can say yum makes the process heavier by dragging in an (almost uncrosscompilable) python, libxml, etc than would be the case with an rpm native solution. Maybe such a solution would have a smaller memory footprint[1].
xml was chosen b/c: 1. didn't have to play games with which language good parse it 2. you could check it for consistency 3. you could extend it and and add revisions that could be counted on
But the XML is all generated from out of the RPM headers again AIUI. The RPM headers seem to be the lingua franca here.
4. originally, we had worked on the xml-metadata to include package information for solaris and deb packages. Not just rpms. You'll notice there is a format-specific tag section in the xml-metadata for that reason.
Well that is good for yum to have such admirable cross-distro plans, but this doesn't deliver anything for the individual distros in terms of Fedora installing .debs if I understood you.
It seems there may be going to be more engineering pointed at rpm than heretofore, seems a good time to raise the role of rpm going on.
-Andy[1] I was updating a friend's machine from FC4 -> FC5 a few weeks ago, Anaconda overcommitted the 256MB in the box by 100MB of swap while musing on packages early on in the process and showed no signs of movement for a couple of hours. FC5 Anaconda doesn't have yum in AFAIK but just saying, memory footprint is an issue even on Desktop boxes.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
