[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