Hi,
It should be really easy to make a script that builds metagroup packages from comps, no?
This will allow someone to install a group such as kde/gnome as an rpm package and when packages are removed/added/changed in the comps groups, the meta group package also changes, and the user gets the appropriate changes.
I don't think this is possible now with the groupinstall feature in yum which IMO is a bad feature since it should be done with meta group packages as I describe.
Comments?
On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote:
Hi,
It should be really easy to make a script that builds metagroup packages from comps, no?
This will allow someone to install a group such as kde/gnome as an rpm package and when packages are removed/added/changed in the comps groups, the meta group package also changes, and the user gets the appropriate changes.
I don't think this is possible now with the groupinstall feature in yum which IMO is a bad feature since it should be done with meta group packages as I describe.
So you want to make packages based on what is in comps?
Whats the point of that if we can just read the comps information itself? -sv
On 8/29/06, seth vidal skvidal@linux.duke.edu wrote:
Whats the point of that if we can just read the comps information itself?
Because it's easier to "yum install kde kde-optional" and have new kde packages added to your system automatically as comps changes.
It's also more intuitive to noobs. "yum install kde" just makes more sense than "yum groupinstall "Some really long string describing the kde group which must be enclosed in quotes which you also have to look up with the yum list groups command which you have to always have to man yum to figure it out every time you run it, and keep in mind that you will have to manually always have to recheck the comps file every so often for every group you install to know if the group has changed, this will mean you will have to keep track of every package in every group and manually figure out changes on your own. good luck"
seth vidal wrote:
On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote:
Hi,
It should be really easy to make a script that builds metagroup packages from comps, no?
This will allow someone to install a group such as kde/gnome as an rpm package and when packages are removed/added/changed in the comps groups, the meta group package also changes, and the user gets the appropriate changes.
I don't think this is possible now with the groupinstall feature in yum which IMO is a bad feature since it should be done with meta group packages as I describe.
So you want to make packages based on what is in comps?
Whats the point of that if we can just read the comps information itself?
Not if you use smart or apt.. these tools don't use comps.xml
Michael
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Wed, 2006-08-30 at 06:27 +1200, Michael J. Knox wrote:
seth vidal wrote:
On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote:
Hi,
It should be really easy to make a script that builds metagroup packages from comps, no?
This will allow someone to install a group such as kde/gnome as an rpm package and when packages are removed/added/changed in the comps groups, the meta group package also changes, and the user gets the appropriate changes.
I don't think this is possible now with the groupinstall feature in yum which IMO is a bad feature since it should be done with meta group packages as I describe.
So you want to make packages based on what is in comps?
Whats the point of that if we can just read the comps information itself?
Not if you use smart or apt.. these tools don't use comps.xml
That's up to them, isn't it? Ask the application maintainer.
-sv
On Tuesday 29 August 2006 14:25, Christopher Stone wrote:
Because it's easier to "yum install kde kde-optional" and have new kde packages added to your system automatically as comps changes.
It's also more intuitive to noobs. "yum install kde" just makes more sense than "yum groupinstall "Some really long string describing the kde group which must be enclosed in quotes which you also have to look up with the yum list groups command which you have to always have to man yum to figure it out every time you run it, and keep in mind that you will have to manually always have to recheck the comps file every so often for every group you install to know if the group has changed, this will mean you will have to keep track of every package in every group and manually figure out changes on your own. good luck"
This is an invalid reasons. The noob wouldn't be using yum directly. They'd be using Add / Remove Software (pirut) and select the KDE Desktop group with their mouse, and any optional packages they want within that group. Puplet will let them know when there are updates, which will be processed by pup. How does your 'metapackage' fit into this scheme?
On 8/29/06, Jesse Keating jkeating@redhat.com wrote:
Puplet will let them know when there are updates, which will be processed by pup. How does your 'metapackage' fit into this scheme?
Puplet only does a "yum check-install" (AFAIK since this is the first time Ive even heard of this app). There is absolutely nothing it does to check if new packages have been added to a group. If a non-optional package is added to a group that no other package depends on, how is the user to know he needs to install this package?
In addition a user may want to have all packages for a group. For example I should be able to select that I want all optional games packages and every time a new game is added to comps, it should be installed on my system automatically. puplet does not do this AFAIK.
On 8/29/06, Christopher Stone chris.stone@gmail.com wrote:
Puplet only does a "yum check-install" (AFAIK since this is the first
er yum check-update I mean...
On Tuesday 29 August 2006 15:15, Christopher Stone wrote:
Puplet only does a "yum check-install" (AFAIK since this is the first time Ive even heard of this app). There is absolutely nothing it does to check if new packages have been added to a group. If a non-optional package is added to a group that no other package depends on, how is the user to know he needs to install this package?
In addition a user may want to have all packages for a group. For example I should be able to select that I want all optional games packages and every time a new game is added to comps, it should be installed on my system automatically. puplet does not do this AFAIK.
*shrug* I'm not sure users want to constantly get more and more packages added to their install, vs just the existing packages updated. Typically RHL/Fedora releases wouldn't change comps for the duration of the release, but with Extras and new packages being added all the time, comps can get updated. Blindly adding new packages to a user's install isn't the way, perhaps if the user launches pirut it can notice that new packages have been added to the pool and do a interesting popup or a window that says "new packages added to the pool: foo in group Bar baz in group Zing
and let the USER decide if they want to add those packages or not.
Jesse Keating (jkeating@redhat.com) said:
*shrug* I'm not sure users want to constantly get more and more packages added to their install, vs just the existing packages updated. Typically RHL/Fedora releases wouldn't change comps for the duration of the release, but with Extras and new packages being added all the time, comps can get updated. Blindly adding new packages to a user's install isn't the way, perhaps if the user launches pirut it can notice that new packages have been added to the pool and do a interesting popup or a window that says "new packages added to the pool: foo in group Bar baz in group Zing
and let the USER decide if they want to add those packages or not.
So, to do this you'd need to keep track of the *previous* state of the comps and do (essentially) a diff. The metadata at the moment isn't set to store this information.
Napkin-ing this, you'd compare it, see the new packages, and then pop up:
New software available in the 'Games' group:
GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer
[ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ]
or something along those lines.
Bill
On Tue, 2006-08-29 at 15:47 -0400, Bill Nottingham wrote:
Jesse Keating (jkeating@redhat.com) said:
*shrug* I'm not sure users want to constantly get more and more packages added to their install, vs just the existing packages updated. Typically RHL/Fedora releases wouldn't change comps for the duration of the release, but with Extras and new packages being added all the time, comps can get updated. Blindly adding new packages to a user's install isn't the way, perhaps if the user launches pirut it can notice that new packages have been added to the pool and do a interesting popup or a window that says "new packages added to the pool: foo in group Bar baz in group Zing
and let the USER decide if they want to add those packages or not.
So, to do this you'd need to keep track of the *previous* state of the comps and do (essentially) a diff. The metadata at the moment isn't set to store this information.
Napkin-ing this, you'd compare it, see the new packages, and then pop up:
New software available in the 'Games' group:
GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer
[ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ]
or something along those lines.
You should be able to just run groupinstall again and it will only install the new stuff in that comps group.
-sv
seth vidal (skvidal@linux.duke.edu) said:
Napkin-ing this, you'd compare it, see the new packages, and then pop up:
New software available in the 'Games' group:
GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer
[ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ]
or something along those lines.
You should be able to just run groupinstall again and it will only install the new stuff in that comps group.
But we don't: a) store what groups are installed on the box, to know how to automatically do this b) users may want to know about new optional packages, that this won't catch
Bill
On Tue, 2006-08-29 at 15:58 -0400, Bill Nottingham wrote:
seth vidal (skvidal@linux.duke.edu) said:
Napkin-ing this, you'd compare it, see the new packages, and then pop up:
New software available in the 'Games' group:
GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer
[ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ]
or something along those lines.
You should be able to just run groupinstall again and it will only install the new stuff in that comps group.
But we don't: a) store what groups are installed on the box, to know how to automatically do this
yum can more or less generate that based on what is currently installed.
b) users may want to know about new optional packages, that this won't catch
true enough.
-sv
On Tuesday 29 August 2006 15:47, Bill Nottingham wrote:
So, to do this you'd need to keep track of the *previous* state of the comps and do (essentially) a diff. The metadata at the moment isn't set to store this information.
Not necessarily. It doesn't necessarily have to be a comps group that changed. Could be "I didn't have a cached entry for this package before, this is a new one to me, lets throw a popup". Yum knows about what it knows about (right?), and anything new could be flagged as new, and thus get the popup. Would cover packages that are new that aren't in any comps group too (although you might want to filter those by default...)
Napkin-ing this, you'd compare it, see the new packages, and then pop up:
New software available in the 'Games' group:
GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer [ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ]
or something along those lines.
Yeah, that makes some kind of sense. Would be a cool way of getting new packages into the hands of users.
On Tue, 2006-08-29 at 16:14 -0400, seth vidal wrote:
On Tue, 2006-08-29 at 15:58 -0400, Bill Nottingham wrote:
seth vidal (skvidal@linux.duke.edu) said:
Napkin-ing this, you'd compare it, see the new packages, and then pop up:
New software available in the 'Games' group:
GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer
[ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ]
or something along those lines.
You should be able to just run groupinstall again and it will only install the new stuff in that comps group.
But we don't: a) store what groups are installed on the box, to know how to automatically do this
yum can more or less generate that based on what is currently installed.
Not reliably if the contents of groups change.
Jeremy
On Tue, 2006-08-29 at 16:30 -0400, Jeremy Katz wrote:
On Tue, 2006-08-29 at 16:14 -0400, seth vidal wrote:
On Tue, 2006-08-29 at 15:58 -0400, Bill Nottingham wrote:
seth vidal (skvidal@linux.duke.edu) said:
Napkin-ing this, you'd compare it, see the new packages, and then pop up:
New software available in the 'Games' group:
GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer
[ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ]
or something along those lines.
You should be able to just run groupinstall again and it will only install the new stuff in that comps group.
But we don't: a) store what groups are installed on the box, to know how to automatically do this
yum can more or less generate that based on what is currently installed.
Not reliably if the contents of groups change.
agreed.
-sv
On Tue, 29 Aug 2006, seth vidal wrote:
On Wed, 2006-08-30 at 06:27 +1200, Michael J. Knox wrote:
seth vidal wrote:
On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote:
Hi,
It should be really easy to make a script that builds metagroup packages from comps, no?
This will allow someone to install a group such as kde/gnome as an rpm package and when packages are removed/added/changed in the comps groups, the meta group package also changes, and the user gets the appropriate changes.
I don't think this is possible now with the groupinstall feature in yum which IMO is a bad feature since it should be done with meta group packages as I describe.
So you want to make packages based on what is in comps?
Whats the point of that if we can just read the comps information itself?
Not if you use smart or apt.. these tools don't use comps.xml
That's up to them, isn't it? Ask the application maintainer.
Apt used to have support for comps.xml with the previous format of comps.xml in the form of a plugin and it's certainly on the todo-list to resurrect the functionality one way or the other.
As for metapackages, JUST SAY NO. I've been down that path, they are nothing short of hidous to deal with. Carefully handcrafted metapackage(s) *might* make sense in some specific environments / cases but automatically generated humongous dep-bloat comps-metapackages are nothing but pain, pain, pain.
- Panu -
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Christopher Stone -
Jeremy Katz -
Jesse Keating -
Michael J. Knox -
Panu Matilainen -
seth vidal