Development -> Release use of --oldpackage

[Andy Green]

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.
-------------- 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://listman.redhat.com/archives/fedora-devel-list/attachments/20060903/892b7926/attachment.bin>