On Mon, 27 Jan 2014 21:28:37 -0500
Shawn Starr <shawn.starr(a)rogers.com> wrote:
I previously worked with Red Hat on their Red Hat HPC Solution (our
original Fork/redo of NPACI Rocks which was.. difficult). It's
We had the concept of kits to do metapackages. I have the last CVS
snapshot code available for people to examine. I will have to mirror
it somewhere as my laptop as a VM/web server can only handle so much
The concept was this:
kit-something ---> pulls in: kit-client-configs / kit-server-configs
<--- pulls in RPM dependencies for packages. Kits == Roles basically.
Now, we didn't have comps.xml to work with but we could maybe do
something like: We have a roles.xml which maps to comps.xml groups.
So, then "Fedora Server Role" maps to X groups in comps.xml which
pulls in the direct RPM dependencies.
The "Fedora Server Role" RPM/whatever can have then its own "turn
key" configuration template/setup files for the groups it pulls in to
configure them out-of-the-box.
role-something ---> pulls in: role-client-configs /
role-server-configs <--- pulls in comps.xml group package RPM
dependencies as part of each grouping
That way, we dont break existing users where a Desktop also contains
server configurations (comps.xml -> RPM dependencies only) and we
gain the ability to have a higher-level grouping which adds on
turn-key meta configurations that are *optional*.
So its a one way-dependency mapping and both use cases win!
metapackages have a number of issues... see the cons section of:
In the case of just a 'fedora-server-freeipa' role, they make sense to
me, as if someone removes a specific package that this role needs, it
would remove the role package, which is fine, since they would no
longer be using the role.
I'm not sure what deeper level you are suggesting here, can you provide
a more detailed example?