[Yum-devel] group DB

Tim Lauridsen tim.lauridsen at googlemail.com
Sat May 23 06:24:09 UTC 2009


On 05/23/2009 12:12 AM, James Antill wrote:
>   Some thoughts about group DB (having groups as real objects). I mainly
> wrote this for me, to see if "group DB" was actually possible. I think
> so :).
>
> I think the "big" issue people want to change is that given:
>
> 	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:
>
> 	yum groupinstall KDE
> 	yum remove blah-package-in-KDE-group
> 	yum groupupdate  KDE
>
> ...you don't have blah added at the end. The last interesting feature is
> that given:
>
> 	yum groupinstall KDE
> 	# packages added to group KDE
> 	yum update
>
> ...you have the new KDE packages.
>
> I think this means that we have to know:
>
> 1. Which groups are installed.
>
> 2. Which package names were in the group. This is more complicated as we
> have to manage not to ping pong when repos. are enabled/disabled, so
> probably needs some repo. data).
>          This lets us add new packages on "yum update".
>
> 3. If a package was installed via. groupinstall/groupupdate.
>          This lets us know to remove those (and only those) on a
>          groupremove.
>
> 4. Which "package names" in a group are blacklisted.
>          This might be as simple as "group X is installed, and pkg FOO
>          isn't new and isn't installed ... thus. blacklisted"
>
> ...a couple of things that fall out of this:
>
> i. You can have all the packages for a group installed, but the group
> not installed.
>
> ii. You can have a group installed, but no packages from that group
> installed.
>
>    
> ------------------------------------------------------------------------
>
> _______________________________________________
> Yum-devel mailing list
> Yum-devel at lists.baseurl.org
> http://lists.baseurl.org/mailman/listinfo/yum-devel
>    
We have to have a very solid definition of what a group is, so people 
can understand what it is.

1. Fixed groups: it can be like a user group and named container with 
some members.

- the groupremove,groupupdate commands will work on the current 
installed members in the group.

- groupinstall will create the create the group and populate it with 
members. the hard part is to decide what member to put into the group.

   A. All the mandatory+default members ?
   B.  All the not already installed mandatory+default members ?

The group should keep the same members as when it was installed with 
groupinstall and is only removed if all
members are no longer installed (by groupremove or by remove), so the 
group can't be empty.

For this kind of group we have to store the groups somewhere and remove 
empty groups after each yum transaction.
if B is selected then all packages can be installed with out the group 
is installed.


2. Dynamic groups:  it can be like a checklist with some predefined 
tasks (list of packages). the group is only installed if all tasks are 
checked.  (like today)

groupinstall will install all missing members on the list.

groupremove will remove all the members on the list, also the ones not 
installed by groupinstall.
groupupdate will update the all names on the list.

The problem here is if you remove one package from the list, then the 
group no longer is installed and groupremove and groupupdate don't make 
sense any more.

We don't need any kind of group storage, then dynamic groups are 
calculated at run time.

Tim




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.baseurl.org/pipermail/yum-devel/attachments/20090523/879be0f3/attachment.htm>


More information about the Yum-devel mailing list