History

GroupSimilarPackages

Here we'd like to come up with a robust method for grouping packages together.

See :

Grouping similar packages

(andre999)

First, I'd like to present the basic concept.
It would be useful to have a model for the presentation of packages, for inquiry or installation, that will satisify both beginning and advanced users, without special configuration according to the level of the user.
Already, according to the categories we are inheriting from Mandriva, packages are divided into groups.
Each of these catagories is tagged as a "group" in the rpm package "spec" files.
However, installing one application (or major package) often entails installing tens (or hundreds) of other packages, many of which are now in the same rpm "group".
As well, often there are many packages associated with a particular application, of which only one or a few would often be selected.
A good example of this is localisation packages, or optional supplementary modules.
Thus a beginning user (and most advanced users most of the time) is presented with an enormous selection of packages, most of which are not relevant at best, and generally confusing.
The concept is to fold auxiliary packages into one expandable line, much as the groups are expandable in the package manager rpmdrake, or the XDG menu system, or the (gnome) nautilus file manager, all currently used by Mandriva.
Like this, an advanced (or curious) user need just expand a line to see associated packages, but by default will be presented a relatively compact and easier to digest set packages.

Note that the idea is to use this model where-ever a user will encounter package inquiry or installation, to provide a uniform user interface.
Besides making it easier for the user, it will facilitate supporting users as well.

Next, we have to decide how to do it.
Let's look at the types of related packages.

type-1) Packages which will (at least almost) always be installed with the primary package.

A good example is the core packages of a multi-package application, like OpenOffice (or their forks Go-oo or LibreOffice).

type-2) Associated packages where normally only one or several of many packages will be installed.

A good example is localisation packages (one or a few per language), as with Firefox, OpenOffice.

Another example, for more advanced users, is the many versions of the Linux kernel.

type-3) Packages which fall between, such as optional extension modules.

For applications like Firefox, OpenOffice, and many others.

Considering these different types of relations, I would suggest folding only the first type under the primary package.
And using task packages to present the second and third types folded on lines following the primary package.
I'll discuss this in more detail furthur down.

Possible solutions :

Solution-1)
The seemingly simplist approach would to fold all dependant packages under a primary package.
But that wouldn't be all that simple.
Often "fooa" and "foob" are mutually dependant. In addition to dealing with the complexity of analyzing mutual dependance, how do we decide which is the primary package ?
We could always leave it to chance, but that would not necessarily be the best choice.
As well, even without mutual dependancies, analyzing dependancies requires following a chain of dependancies enumerated in the spec file of each package, which could be time-consuming as well.
And what about conditional dependancies ?
And what do we do with type-2 and type-3 relations, as enumerated above ?
It gets complicated.
It would be better to have a solution simpler to apply.

Solution-2)
I had the thought of using a supplementary field in the rpm spec file, to indicate the primary package.
If such a field doesn't already exist, it must be added.
My knowledge of spec files is too limited at the moment.
If anyone has ideas on this, their contribution is welcome.
This approach would require the packager to indicate associations.

Solution-3)
There was the suggestion to use the beginning of the package name for grouping.
In the simplist form, this can give a lot of false associations.
(Just think of "perl")

But it gave me an idea :
Note that ":" is rarely if ever a part of a package name. So we can use ":" as a separator.
Suppose the primary package is "foo". Then we can give secondary packages names such as "foo:suba", "foo:subb", etc.
In other words, secondary packages would have names starting with

primary-name + ":",

with a differentiating sub-name

And what would we name type-2 or type-3 packages, to be folded on lines following the primary package line ?
Assuming that we can readily identify a meta-package, we could call the meta-package

primary-name + ":" + meta-name

and the contained packages

primary-name + ":" + meta-name + ":" + submeta-name

This approach would require the packager to indicate associations, but has the advantage of not touching the rpm spec file, and being apparent in the package name.
The latter factor making it easier for the packager to confirm the associations made, as well as simpler for any program to apply them.
(A simple sort of package names will put the associated packages in order.)
A possible disadvantage is that many packages would no longer have upstream names. I welcome input on this (and other) points as well.

Note that solutions (2) and (3) would require packager designation of folding groups.
So we would have to have guidelines for this, as well as cooperation from the packagers.
For third-party packagers, this could be problematic.
If an appropriate field exists already in the rpm format, and a single Mageia-focused rpm package could adjust related package info, then OpenOffice, for example, could potentially adjust to solution-2. Similarly for solution-3, if an equivalent magic could be done on package names.

Also, if meta-packages are used for grouping related packages, we could additionally show other meta-packages as a folded list of contained packages.
In addition to allowing easier examination of meta-package contents, this would facilitate installing all but some of a selected meta-package, by deselectiong parts one doesn't want. (Limited, of course, by spec-file dependancies.)
An interesting side effect of the folding mechanism.

We don't (yet) have a workable solution for automatic designation of folding groups.

Open to discussion :)

Openoffice.org example

OpenOfficeExample