seth vidal wrote:
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.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.except that it didn't.
Oh well.
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.
Hum well I guess that it is folks on dialup or whatever that tend to update the least often, ensuring a pile of new headers that would be interesting. Whereas with your current method they just get the compressed XML file once. That can clearly be a win for the compressed summary method.
But for people who have the nightly yum going, it can be a win for the header method if stuff is changing at most a few packages every day.
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].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.- 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?
I'm talking about crosscompiling. There's a short rant here describing why there is a problem and why it is a problem.
http://warmcat.com/_wp/?p=17It's not your problem, and Fedora doesn't mind either since they already have system-config-* stuff done in Python and so have to have it in a minimal install. But it does raise the price of doing package management using these mainstream tools on much smaller boxes.
But the XML is all generated from out of the RPM headers again AIUI. The RPM headers seem to be the lingua franca here.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 onGo read how yum 1.0.X did things, then come back and tell me again how wonderful the rpm headers are.
I'm just saying they are the raw material. Ultimately yum is eating them via XML, and rpm eats them from the package, rpm maintains a database them. If you have a link to some great yum 1.0 battle I can read up on I will do so.
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.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.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.
I think I did get your point, what I don't see is what that delivers for, say, Fedora that a Solaris repo has the same metadata.
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.
I guess either rpm should grow if it makes sense to perform natively any of the higher depsolving actions, or it should shrink to lose functionality that is duplicated in yum. It seems things like rpmio, xml and yaml cannot currently be chopped out at ./configure time at least not according to the configure help. It would only be an improvement to rpm if you could pick and choose what to build with a bit finer granularity.
yes, fc5's anaconda is using yum.
That actually makes me feel better about it, because when I go around there next time to give them FC6 at least it might take no longer with the 384MB they have now.
If you load rpms/headers into a transaction set things get big.
In my experience package management is now the single most memory-demanding action a box may ever experience, and it is defining the minimum memory needed for the whole OS. If most of that allocation is coming out of librpm, and there is currently interest in looking at rpm harder, memory footprint reduction would be nice for everyone.
-Andy
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
