On Sun, 2006-09-03 at 21:49 +0100, Andy Green wrote: > > 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. We considered producing per-package xml files and the big collection of them so we could optimize both ways. It just ate room on mirrors and was hard to tell when one would be a win over the other for any given connection. > >>> 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. > > 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. go look on the yum mailing list for the first couple of years. > 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 doesn't. Yum predates fedora. yum was first released when rhl 7.2 was current. The point was to make it so the various pkging people could come together on SOMETHING rather than constantly having one-off formats. The more often you have people come to the same table the better chance you have for other collaborations. > 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. I think less code is good. especially less code where fewer people can be involved in it. rip rpmio, yaml, xml, etc right out of rpm. Strip rpm down to a library and an extremely basic cli. Do the rest of the tools and what-not using the library in higher-level languages. Bring rpm-build out into its own package that just uses the library. Starting doing some real changes to how rpm's get built. Maybe even have it tie in closer to our current buildroot mechanism. Think about it. A spec file that could tell you what distro it was designed for - maybe even the chroot conditions. > 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. I agree. This is why we want to get rpm out of the doldrums it has been in for the last 2 years or so. Since rpm 4.1.X not a lot has changed to make rpm better/faster/stronger. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
