[Yum-devel] [RFC] dbversion 10

James Bowes jbowes at redhat.com
Tue Apr 10 13:43:24 UTC 2007


seth vidal wrote:
> Leave header_start and header_end in place for the next cycle. When we
> move to yum ver+2 then we can drop it.

Fair enough.

> I agree with what you've suggested here but we'll need to figure out how
> to make yum-metadata-parser know how to do generate either db format so
> that people making repos don't get caught out in the cold.
> 
> ie: I will still want to be able to make repos with the right db formats
> available on my rhel5 boxes for my fc6, f7 and f8 boxes, of course.

We have two options (that I see): parallel-installable
yum-metadata-parsers or add another parameter that lets you specify the
db version. I'll bet that most people will prefer the second option.

i'd say we add a function like supported_db_versions() to
sqlitecachec.py that returns a list of the dbversions it knows about,
and add a dbversion parameter to RepodataParserSqlite.__init__().
__init__ must then be able to raise an UnknownDbVersion exception.

I think I should be able to redo my ymp patch to support generating both
dbversions in short order, if everyone thinks this is sane.


> 
> Then yum will need to be modified to search through multiple
> 'primary_db' entries in the repomd.xml to figure out which one it can
> use. In fact, that will need to be backported to 3.2.X once it comes out
> to make sure we don't break those, too.

If possible, let's keep yum simple and only support one dbversion. So
yum will ask the repomd.xml for a sqlite file of version X, and if the
repomd doesn't have it, then yum can fall back to generating it itself.

I think this is what you're saying, but I'd suggest that we ignore the
case of upgrades, ie only list one dbversion in the repomd.xml, and only
change it when the distro updates.

> does that make sense to you?

Yep. stupid numbers showing that its faster to download the sqlite file
than to download the xml and parse it :P

-James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20070410/37bd016d/attachment.pgp 


More information about the Yum-devel mailing list