[Mageia-discuss] Introducing mageia-app-db

[Samuel Verschelde]

Le mardi 9 novembre 2010 05:57:36, andre999 a écrit :
> 
> Samuel Verschelde a écrit :
> >
> > Le vendredi 5 novembre 2010 06:38:14, andre999 a écrit :
> >    
> >> As far as the question of application/package view goes, folding entries
> >> (as in Rpmdrake groups or Nautilus) which expands to multi-line would be
> >> nice.
> >> That way complex packages like Openoffice or Firefox could be folded
> >> into 2 or 3 lines.
> >> (1 for localisation, another possibly for optional modules, another for
> >> core modules.)
> >> Now Firefox is more than 100 packages.
> >> This sort of suggestion has been made for Rpmdrake.
> >> The advantage of this approach is that the minimised view could be the
> >> default, and at any time it can be expanded to show all packages,
> >> without any configuration settings.
> >>      
> > I'm not against, however how can we define those groups ? Is there a way to automate it ? Is it necessary to define it manually (and so to maintain it so have maintainers of these groups definitions) ?
> >    
> First of all, the idea is to continue to use Mandriva-like categories 
> for the packages, as in Rpmdrake.  So we associate packages within these 
> larger categories.
> 
> The basic idea is to establish a hierarchy of views for multi-package 
> applications.
> These associations should be designated according to guidelines, which 
> are yet to be established, according to the best judgement of the packager.
> 
> Otherwise I don't see how we can arrive at consistant and useful 
> associations, especially if being used by different applications, like 
> Rpmdrake and your (very interesting and useful) project.  It is 
> important that such applications are able to discern these associations, 
> in order to display them.
> 
> First it will be useful to look at the different types of associations :
> 1) Where usually all of the associated packages would be installed, such 
> as core packages of OpenOffice or Go-oo or LibreOffice.
> 
> 2) Where usually only one - or a few - of the associated packages would 
> be installed, such as localisations.
> 
> 3) Something in between, such as optional extensions for Firefox
> 

I read your whole post (had to come back 2 times to manage to finish it ! :)). 

Some comments :
- using a new tag to group packages together may be a solution for packages which have many optional subpackages, however this means we must reach a consensus among packagers. A complete proposal which have been tested on most of the examples you brought in your post could maybe help convincing other packagers. Adding a new tag is not a trivial move and maybe could break some compatibilty with other distributions, so I think it must be "proved" that it is the best solution (if it is).
- another simple way could be to group by source rpm. It won't always work, but that can be a first step, to experiment with.
- task meta-packages can be another solution
- we may have a look at what a package provides and group together packages whose names are close and which provide the same thing (eg. all packages which provide "openoffice.org-l10n" grouped together)
- it would be interesting to look at other distributions, to see how they solved or tried to solve this problem. How does ubuntu in its package manager for example ?

If you have some free time and motivation, while we're waiting for the build system, you could maybe help us define how to show packages to users in mageia-app-db. If we can define a robust algorithm for package grouping, we'll try to implement it.

Another problem you mentioned is how to define what an "application" is. We could use some help on this subject too :)

You can have a look at this wiki page (on our new Redmine project, thanks to Jehane for setting it up) which is dedicated to this matter : http://mageia-app-db.tuxette.fr/projects/mageia-app-db/wiki/Applications

Regards

Samuel Verschelde