On Sun, 2006-09-03 at 19:42 +0100, Andy Green wrote: > 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. up2date had rhn. Not exactly something we can duplicate - if only b/c rhn is not mirrorable in any traditional sense. > > 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. except that it didn't. > > 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. yum is getting the headers of the packages you'll actually use. Not the ones for EVERY package. If you want to see the hate-filled-screeds from the past- feel free to look up what people said when yum downloaded every single header, no matter what. It downloaded gzipped individual headers. And the pronouncement was that it was causing such problems for people on narrow connections. > > 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]. - libxml2 isn't used anymore - yum works on i386, x86_64, alpha, sparc, arm, ia64, ppc and the s390s. What other platform is it that python doesn't work on? > > 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. Go read how yum 1.0.X did things, then come back and tell me again how wonderful the rpm headers are. > > 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. you didn't understand me. The goal was for us all to be using the same metadata type for repositories. Not so we'd all be using one tool. > 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. The answer, imo, is to remove things from rpm. Get rid of all the cruft like rpmio, the xml-output, the yaml output. Make rpm only check deps and do file install/removal/verification. > [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 yes, fc5's anaconda is using yum. > but just saying, memory footprint is an issue even on Desktop boxes. if you want to conduct a fun test: rpm -Uvh bigdirofrpms then see what the memory footprint looks like. If you load rpms/headers into a transaction set things get big. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
