Development -> Release use of --oldpackage

[Andy Green]

seth vidal wrote:

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

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.

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

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=17

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

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

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4492 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060903/ffb47134/attachment-0002.bin