[Yum-devel] group DB

[James Antill]

On Wed, 2009-05-27 at 06:22 +0200, Tim Lauridsen wrote:
> On 05/26/2009 09:21 PM, Jeremy Katz wrote:
> > There's still some amount of fiddles and bits perhaps required due to
> > repo enabling/disabling.  But it feels a little bit better if we can get
> > the information into the rpmdb rather than more and more dbs in more and
> > more places...
>
> The importent part is to define the user cases and how we what the 
> different cases and look if it can be done
> without adding extra databases.
> 
> Ex.
> 
> 	yum install blah-package-in-KDE-group
> 	yum groupinstall KDE
> 	yum groupremove  KDE
> 
> ...you have blah left at the end. The other desire is that given:
> 
> If we add a 'KDE' tag to the yum pkg info db to the packages installed by
> 'yum groupinstall KDE'
> 
> then 'yum groupremove  KDE' could:
> 
> 1. get the list of packages from comps in the KDE group.
> 2. remove the ones the has a 'KDE' tag.

 Yeh, we could work out some way to store this in the yumdb. I'm
reluctant to try that for a couple of reasons though:

1. We don't often think of pkgA is a member of groups X, Y and Z but of
group X contains packages pkgA and pkgB. So modeling it backwards just
seems wrong, and indeed things like "give me all installed packages in
group X" would requiring searching through all packages in the yumdb.

2. The problems to do with blacklisted packages (use case #2 in my
original email) and enabling/disabling repos. seem much harder to model
in yumdb.

>  but i could be an idea to put comps into an sqlite db for faster access, it don't change very often
> so no need to waste time to build the structures every time.

 Yeh, someone's mentioned that a couple of times recently ... I don't
think CPU time is a large burden (at least atm.), but parsing the xml
and keeping everything in core does suck up memory.
 Having groups_db, groups_gz and groups will be "fun" ...but, meh.

-- 
James Antill <james at fedoraproject.org>
Fedora