[Mageia-discuss] Introducing mageia-app-db

[andre999]

Samuel Verschelde a écrit :
> 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 ! :)).
Hope that's good :)
> 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).
>    
I understand.

> - 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)
>    
Excellent points.  Which gives me an idea how to accomplish folding, 
without changing the internals of the rpms :
First, note that very few if any package names contain ":".
So to fold packages associated with package "foo", on the line of "foo", 
we could name the associated packages "foo:suba", "foo:subb", etc, 
beginning with the name of the primary package + ":".
To fold associated packages on a subsequent line (as would be useful for 
localisation packages, for example), we would create a meta-package 
"foo:subc".  Seeing that it is a meta package, the packages under it 
would be folded into a line *under* "foo".  And expanding the 
meta-package line would show all contained packages.
Other meta packages (without ":" in the name) would be similarly 
expandable.  The only difference being that they would not be associated 
with another group of packages.
This approach has the advantage of leaving the internals of rpm 
unchanged for this purpose.
One just adds ":" to the name of associated packages, and creates some 
grouping meta-packages.
Actually I'm assuming that there is a means of readily identifying a 
meta-package other than "task" in the name.  Correct me if I'm wrong.

Another advantage is it lets users more readily see the packages 
contained in a meta-package.  And in installing, potentially allows 
deselecting a package contained in a meta-package to be installed.
(Yes, I know, a meta-package only refers to other packages, not 
containing them.)

Of course it still needs consensus by the packagers - but it is a lot 
easier to implement, and probably more reliable as well.

> - 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 ?
>    
Good idea.  Good to look at Suse as well, as they have made a number of 
enhancements to rpm.
> 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.
>    
I think we are getting closer.  I'll give this priority.
> Another problem you mentioned is how to define what an "application" is. We could use some help on this subject too :)
>    
That is definitely tricky.  It should probably be more than just GUI.
It might be simpler to just rely on folding ? (What is specifically 
folded with what will be ultimately decided by the packager.)
> 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
>    
So I imagine my thoughts go under "crazy ideas" ? ;)
(I like how the wiki page is set up.)

BTW, I really appreciate your comments.  Makes me think :)

If anyone has any ideas relating to this, don't hesitate to comment ...
> Regards
>
> Samuel Verschelde
>    

- André