Hi,
I'd like to see some guideline on when meta-packages should / can / can't be created for Fedora. It is definite that examples do currently exist, eg: xorg-x11-drivers
I did dig up some old info, but it seems nothing made it into the wiki as a guideline. Can this be discussed and a suitable doc make it into the Guidelines ?
[1] http://thread.gmane.org/gmane.linux.rpm.general/12588/focus=12589 [2] http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/3735 [3] https://bugzilla.redhat.com/show_bug.cgi?id=351571
It seems, that for the most part the preference should be to create a comps group, and add all the packages that would be required if it was a meta-package as "required" within the comps group. The package management tools (yum and PackageKit) can then be used with group options to install or remove the group.
It seems there is some limitations on using comps groups (please correct me if these are solvable another way): - such a group can not cause the requiring of for example an i386 package on an x86_64 machine.
- to workaround (rpm 4.x limitations) above, such a group can not cause the requiring of an i386 package by requiring a file only available in the i386 package.
Cheers, David Timms.
On Tue, Jan 13, 2009 at 12:29:32AM +1100, David Timms wrote:
Hi,
It seems there is some limitations on using comps groups (please correct me if these are solvable another way):
- such a group can not cause the requiring of for example an i386
package on an x86_64 machine.
- to workaround (rpm 4.x limitations) above, such a group can not cause
the requiring of an i386 package by requiring a file only available in the i386 package.
Also some packages of the group can be removed, while a meta-package prevents that, as long as the meta-package itself is present. This can also be seen as an advantage, depending on the situation, but it is definitely a difference.
-- Pat
Patrice Dumas wrote:
Also some packages of the group can be removed, while a meta-package prevents that, as long as the meta-package itself is present. This can also be seen as an advantage, depending on the situation, but it is definitely a difference.
And in my situation removing any package in the "group" would break the external software that the meta package has simplified the install of.
DaveT.
Le Lun 12 janvier 2009 14:43, David Timms a écrit :
Patrice Dumas wrote:
Also some packages of the group can be removed, while a meta-package prevents that, as long as the meta-package itself is present. This can also be seen as an advantage, depending on the situation, but it is definitely a difference.
And in my situation removing any package in the "group" would break the external software that the meta package has simplified the install of.
However we do not change out package layout to accommodate external software. Please keep your external software adaptation layers outside the Fedora repository.
Nicolas Mailhot wrote:
Le Lun 12 janvier 2009 14:43, David Timms a écrit :
And in my situation removing any package in the "group" would break the external software that the meta package has simplified the install of.
However we do not change out package layout
I'm not sure where you think I asked to do such a thing ?
to accommodate external software.
Please keep your external software adaptation layers outside the Fedora repository.
Since you read my mind on "external software", I'll mention that I considered this to be a separate issue, I have a separate query/discuss/request that I'll post soon.
DaveT.
2009/1/12 Patrice Dumas pertusus@free.fr:
On Tue, Jan 13, 2009 at 12:29:32AM +1100, David Timms wrote:
Hi,
It seems there is some limitations on using comps groups (please correct me if these are solvable another way):
- such a group can not cause the requiring of for example an i386
package on an x86_64 machine.
- to workaround (rpm 4.x limitations) above, such a group can not cause
the requiring of an i386 package by requiring a file only available in the i386 package.
Also some packages of the group can be removed, while a meta-package prevents that, as long as the meta-package itself is present. This can also be seen as an advantage, depending on the situation, but it is definitely a difference.
My perception (which may be incorrect) is that the general use case for meta packages is to simplify the installation of a group of subpackages of one package. Whereas the use case for comps groups seems presently more targeted towards installation of a larger set of packages which are often not subpackages. If that is a correct perception, it suggests that this isn't an either/or question, as comps groups and meta packages are solving different but related situations.
J.
Le Lun 12 janvier 2009 14:49, Jonathan Underwood a écrit :
My perception (which may be incorrect) is that the general use case for meta packages is to simplify the installation of a group of subpackages of one package. Whereas the use case for comps groups seems presently more targeted towards installation of a larger set of packages which are often not subpackages.
Just because a comps group can easily handle packages from different origin does not mean you should not use it for subpackages generated from the same srpm.
2009/1/12 Nicolas Mailhot nicolas.mailhot@laposte.net:
Le Lun 12 janvier 2009 14:49, Jonathan Underwood a écrit :
My perception (which may be incorrect) is that the general use case for meta packages is to simplify the installation of a group of subpackages of one package. Whereas the use case for comps groups seems presently more targeted towards installation of a larger set of packages which are often not subpackages.
Just because a comps group can easily handle packages from different origin does not mean you should not use it for subpackages generated from the same srpm.
Sure, agreed.
A key difference though is that other packages can't Require a comps group, but they can Require a metapackage. I can see why that could be considered bad practice.
Also, using comps groups for the metapackage use case I outlined would lead to many more compsgroups, themselves much smaller than the presently existing comps groups.
Perhaps we need another concept - collections and groups, where collections is roughly what we currently call comps groups (large package sets with a big overall functionality payload like a desktop environment etc) and comps groups which are primarily for pulling in a series of subpackages. This would lose the ability for a metapackge to be Required now. But perhaps requiring a metapackage is bad practice anyway.
J.
Le Lun 12 janvier 2009 15:02, Jonathan Underwood a écrit :
Also, using comps groups for the metapackage use case I outlined would lead to many more compsgroups, themselves much smaller than the presently existing comps groups.
If you look at the comps groups of past releases, you'll see that creating groups with half a dozen packages inside has been done before, and was a common case when comps was introduced. The distribution has massively grown without our comps layout following, probably because no one was perceived to be in chargo of comps those past years.
Perhaps we need another concept - collections and groups, where collections is roughly what we currently call comps groups (large package sets with a big overall functionality payload like a desktop environment etc) and comps groups which are primarily for pulling in a series of subpackages.
There was supposed to be a session on comps future at FUDCON, I hope its results will be posted on the list soon.
Regards,
meta packages will be good.
task-c-devel task-c++-devel task-kde-minimal task-kde task-gnome task-gnome-minimal
etc.....
On Mon, Jan 12, 2009 at 12:20 PM, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Lun 12 janvier 2009 15:02, Jonathan Underwood a écrit :
Also, using comps groups for the metapackage use case I outlined would lead to many more compsgroups, themselves much smaller than the presently existing comps groups.
If you look at the comps groups of past releases, you'll see that creating groups with half a dozen packages inside has been done before, and was a common case when comps was introduced. The distribution has massively grown without our comps layout following, probably because no one was perceived to be in chargo of comps those past years.
Perhaps we need another concept - collections and groups, where collections is roughly what we currently call comps groups (large package sets with a big overall functionality payload like a desktop environment etc) and comps groups which are primarily for pulling in a series of subpackages.
There was supposed to be a session on comps future at FUDCON, I hope its results will be posted on the list soon.
Regards,
-- Nicolas Mailhot
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Mon, 2009-01-12 at 15:20 +0100, Nicolas Mailhot wrote:
Le Lun 12 janvier 2009 15:02, Jonathan Underwood a écrit :
Also, using comps groups for the metapackage use case I outlined would lead to many more compsgroups, themselves much smaller than the presently existing comps groups.
If you look at the comps groups of past releases, you'll see that creating groups with half a dozen packages inside has been done before, and was a common case when comps was introduced. The distribution has massively grown without our comps layout following, probably because no one was perceived to be in chargo of comps those past years.
Perhaps we need another concept - collections and groups, where collections is roughly what we currently call comps groups (large package sets with a big overall functionality payload like a desktop environment etc) and comps groups which are primarily for pulling in a series of subpackages.
There was supposed to be a session on comps future at FUDCON, I hope its results will be posted on the list soon.
We did have a productive, though a little bizarre, meeting on saturday. I'll see what I can write up briefly and one of the others can add to it.
Here's a version of it:
0. There's some code we need before we can do this. So don't go changing anything right away. 1. comps groups will get rid of the 'types' of pkgs - a group being in a package means it is in the group - so no more optional/mandatory/default pkgs. 2. conditionals are going away entirely. 3. we're going to do something fairly radical to make group persistence behave as more people expect it. We're going to build metapkgs on the fly at the yum layer and install them. There's a a lot more to how we're going to do it but this is what was discussed at the meeting.
I'll post more once I get through the rest of my email.
-sv
packaging@lists.fedoraproject.org
-
Development discussions related to Fedora -
itamar -
Jonathan Underwood -
Nicolas Mailhot -
Patrice Dumas -
Rex Dieter -
Seth Vidal