IMHO, I would like to see some of the grouplist functionality put back
into yum. We can work around the change, but I think it is useful for
users doing larger deployments of Fedora.
We have almost 200 Fedora core workstations and support servers in our
department, and the ability to create groups including other groups is a
useful feature. Our systems do a base install during kickstart, and
check their role (workstation, nfsserver, printserver, etc) from the
LDAP server. Each role corresponds to a yum group that is installed.
Under yum 2.2 we could include standard Fedora groups in these 'role'
groups. We don't really need deep recursive expansion, but the ability
to include a set of groups in a group, ignoring included group's groupreqs.
We can rewrite our generate yum groups script to get the package lists
from each standard Fedora group, and include the package list in the
'role' group. This seems a little kludgey, but it can be done. Another
option is a simple workaround to include grouplist again for the cli,
which is neither elegant or probably the proper way to include this
functionality, but as an example.
This isn't a huge deal, but I thought I voice my opinion a little on the
subject. Yum is great, and it has worked very well for us since moving
to Fedora. Keep up the good work.
Will
--- cli.py.orig 2006-04-11 08:31:08.000000000 -0500
+++ cli.py 2006-04-11 08:32:04.000000000 -0500
@@ -1364,7 +1364,9 @@
if not group:
self.errorlog(0, _('Warning: Group %s does not exist.')
% group)
continue
-
+
+ grouplist.extend(group.reqgroups)
+
try:
txmbrs = self.selectGroup(group.groupid)
except yum.Errors.GroupsError, e:
--- comps.py.orig 2006-04-11 08:30:49.000000000 -0500
+++ comps.py 2006-04-11 08:37:26.000000000 -0500
@@ -51,7 +51,7 @@
self.display_order = 1024
self.installed = False
self.toremove = False
-
+ self.reqgroups = []
if elem:
self.parse(elem)
@@ -128,10 +128,20 @@
if self.langonly is not None:
raise CompsException
self.langonly = text
-
+
elif child.tag == 'packagelist':
self.parse_package_list(child)
+
+ elif child.tag == 'grouplist':
+ self.parse_group_list(child)
+
+ def parse_group_list(self, grouplist_elem):
+ for child in grouplist_elem:
+ if child.tag == 'groupreq':
+ groupid = child.text
+ self.reqgroups.append(groupid)
+
def parse_package_list(self, packagelist_elem):
for child in packagelist_elem:
if child.tag == 'packagereq':
seth vidal wrote:
> On Mon, 2006-04-10 at 20:20 -0400, Jeff Sheltren wrote:
>
>> On Apr 10, 2006, at 4:27 PM, Panu Matilainen wrote:
>>
>>> Group dependencies are no longer supported in FC-5 comps/yumgroups.xml
>>> format. I miss them too... but the groupreq got sacrificed for the GUI
>>> gods, expressing the group dependencies in GUI tools doesn't really
>>> work.
>>>
>>> - Panu -
>>>
>> So, I've been curious - is there a new "more better" way to do this
>> in yum 2.6? I get the impression that the comps format (ie.
>> yumgroups.xml) is going the way of the dodo bird. Seth has brought
>> up alternatives for how mock should handle this, but I'm unaware of
>> how "groups" are/will be handled in yum 2.6+. Is this still under
>> development? Is it an underground movement to do away with the
>> segregation of packages? :) If it has already been decided, is there
>> a place I can read about groups support in current versions of yum?
>>
>>
>
> in order to make the gui work we had to minimize some of the crazy
> recursive possibilities of groups and pull out some other difficult
> concepts. I'm not adverse to putting some of the things back in but I'd
> want to make sure it's done in conjunction with things that anaconda
> needs to make sure we don't break the installer for fedora. :)
>
> What functionality is it that you need from the groups and let's see if
> there is a happy medium in here somewhere?
>
> Thanks,
>
> -sv
>
> _______________________________________________
> Yum mailing list
> Yum@xxxxxxxxxxxxxxxxxxxx
> https://lists.dulug.duke.edu/mailman/listinfo/yum
>
--
------------------
William Bear
School of Mathematics
University of Minnesota
W: 612-625-2309
GNUPG Fingerprint: CE5E 3571 CD4C F29C 8089 D0DF B175 26CE 5C27 B748
Thawte Cert MD5 Fingerprint: 05E1 7B63 096F 3CDF 9504 1F64 E23C 3982
------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3217 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.dulug.duke.edu/pipermail/yum/attachments/20060411/b2f214f8/smime-0001.bin
