Changes between Version 2 and Version 3 of YumGroupsOverview
- Timestamp:
- 07/12/13 21:01:11 (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
YumGroupsOverview
v2 v3 9 9 === Pros. === 10 10 11 * Has the bare minimum feature of being able to "install grp-foo" and get a bunch of packages installed.11 * Has the bare minimum feature of being able to "install grp-foo" and get a bunch of packages installed. 12 12 13 * "install" does what the user expects.13 * "install" does what the user expects. 14 14 15 * It's very easy to explain (it's just a package).15 * It's very easy to explain (it's just a package). 16 16 17 * Extra feature: Allows packages to "require a group".17 * Extra feature: Allows packages to "require a group". 18 18 19 * Extra feature: "yum upgrade" will automatically upgrade any installed groups, and install new packages.19 * Extra feature: "yum upgrade" will automatically upgrade any installed groups, and install new packages. 20 20 21 21 === Cons. === 22 22 23 * Removing the group doesn't remove the packages, without outside help. Eg. "yum install git" && "yum remove git".23 * Removing the group doesn't remove the packages, without outside help. Eg. "yum install git" && "yum remove git". 24 24 25 * If you install a "grp-foo", every package is a requirement. This means that removing any package from the group will immediately remove the group.25 * If you install a "grp-foo", every package is a requirement. This means that removing any package from the group will immediately remove the group. 26 26 27 * Each group can only come from a single source. Eg. If you have two repos. A and B that both want to have a group called "mystuff" then you can only have a single package called "mystuff" and it has to come from either A or B.27 * Each group can only come from a single source. Eg. If you have two repos. A and B that both want to have a group called "mystuff" then you can only have a single package called "mystuff" and it has to come from either A or B. 28 28 29 * The UI tends to be full of annoyingly leaky abstraction layers, Eg. "yum group info foo" is really repoquery -qr metagrp-foo. "yum remove metagrp-foo" is actually removing a group.29 * The UI tends to be full of annoyingly leaky abstraction layers, Eg. "yum group info foo" is really repoquery -qr metagrp-foo. "yum remove metagrp-foo" is actually removing a group. 30 30 31 * rpmdb versions will be different depending on just if "a group" is installed or not, as most people think of groups as a way of dealing with packages it is bad to have "the same packages" but different rpmdb versions.31 * rpmdb versions will be different depending on just if "a group" is installed or not, as most people think of groups as a way of dealing with packages it is bad to have "the same packages" but different rpmdb versions. 32 32 33 * Extra feature: Allows packages/groups to "require/conflict/obsolete" other groups.33 * Extra feature: Allows packages/groups to "require/conflict/obsolete" other groups. 34 34 35 35 44 44 === Pros. === 45 45 46 * Has the pretty good features, as you can install or remove a group.46 * Has the pretty good features, as you can install or remove a group. 47 47 48 * "install" does what the user expects, and "remove" does what the user wants more often than metapackages.48 * "install" does what the user expects, and "remove" does what the user wants more often than metapackages. 49 49 50 * It's very easy to explain, if the user asks, as "yum install @foo" is the same as "yum install $(repoquery -gl foo).50 * It's very easy to explain, if the user asks, as "yum install @foo" is the same as "yum install $(repoquery -gl foo). 51 51 52 52 === Cons. === 53 53 54 * "remove" when two groups contain the same package(s) is very unintuitive to the uninitiated. As is the general case when a group is "installed", that contains packages you already have, and then removed taking other packages with it. The failure case of "remove packages I didn't want removed" is thought of as much worse than "didn't remove any packages".54 * "remove" when two groups contain the same package(s) is very unintuitive to the uninitiated. As is the general case when a group is "installed", that contains packages you already have, and then removed taking other packages with it. The failure case of "remove packages I didn't want removed" is thought of as much worse than "didn't remove any packages". 55 55 56 * If you install a "foo", every package is a requirement. This means that removing any package from the group will immediately (silently) remove the group (but leave all the other packages installed.56 * If you install a "foo", every package is a requirement. This means that removing any package from the group will immediately (silently) remove the group (but leave all the other packages installed. 57 57 58 * "yum upgrade" doesn't install packages added to installed groups (in theory this is possible, but it's complicated).58 * "yum upgrade" doesn't install packages added to installed groups (in theory this is possible, but it's complicated). 59 59 60 60 65 65 === Pros. === 66 66 67 * remove, as well as install, does what the users expect. install followed immediately by remove will work the same as "yum history undo last".67 * remove, as well as install, does what the users expect. install followed immediately by remove will work the same as "yum history undo last". 68 68 69 * Don't need to access the repos. (and thus. the network) to perform "yum group remove"69 * Don't need to access the repos. (and thus. the network) to perform "yum group remove" 70 70 71 * You can install a group, but leave out a member (or even mark it to not be installed in the first place). And it's not reinstalled.71 * You can install a group, but leave out a member (or even mark it to not be installed in the first place). And it's not reinstalled. 72 72 73 * "yum group upgrade" can install new members of the group, without forcing the install of unneeded members.73 * "yum group upgrade" can install new members of the group, without forcing the install of unneeded members. 74 74 75 * "yum upgrade" will upgrade all groups.75 * "yum upgrade" will upgrade all groups. 76 76 77 77 === Cons. === 78 78 79 * Installed packages now have 2 states: installed, installed as part of group XYZ.79 * Installed packages now have 2 states: installed, installed as part of group XYZ. 80 80 81 * Users have to actively manage these installed groups, changing a packages state or blacklisting a package from being installed by a group.81 * Users have to actively manage these installed groups, changing a packages state or blacklisting a package from being installed by a group. 82 82 83 * the groups data now needs to be downloaded a lot more often (most notably anytime "yum upgrade" is run).83 * the groups data now needs to be downloaded a lot more often (most notably anytime "yum upgrade" is run). 84 84 85 * This is the hardest to explain to new users, even though it mostly does what they expect.85 * This is the hardest to explain to new users, even though it mostly does what they expect. 86 86 87 * We are storing more data outside of the rpmdb that is really part of the transaction. 88 87 * We are storing more data outside of the rpmdb that is really part of the transaction. 89 88 90 89 = Dealing with the objects = 94 93 Currently the "best" way to do this is with a bunch of yum commands that start with "mark" under the groups subcommand. Eg. 95 94 96 * yum group mark-install foo95 * yum group mark-install foo 97 96 98 97 will make yum believe that a group object is installed without a transaction (or altering any packages). 99 98 100 * yum group mark-remove foo99 * yum group mark-remove foo 101 100 102 101 will make yum believe that a group object is not installed without a transaction (or altering any packages). 103 102 104 * yum group mark-packages foo pkgA pkgB...103 * yum group mark-packages foo pkgA pkgB... 105 104 106 105 will make yum believe that "pkgA pkgB..." were installed as part of the group "foo".