[Mageia-discuss] Introducing mageia-app-db

[andre999]

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

Probably the best way to associate packages is to use an additional tag 
in the package spec file.  In addition to the package "name" tag, have 
an additional tag, let's call it "subname", for the associated package.
(Since I am only beginning to familiarise myself with the details of rpm 
packaging, including the spec file, I don't know if an equivalent a tag 
already exists.  If not, I hope that there is no problem creating one.)

For the first type of association described above, the key package would 
have the "name" tag but not a "subname".  The other core packages would 
have the same "name" tag, being differentiated by a "subname" tag.

For the other types of associations, there would be a meta package with 
a distinct "name" tag; all the real packages using this distinct "name" 
plus a differentiating "subname".
So an application could have its various packages divided into as many 
groups as desired, with all but the core group subsidiary to a meta 
package.  I would suggest that generally one would not want more than 3 
groups for a large application, but this grouping would be left to the 
packager.
As well, related but different applications could be grouped by this 
method, using a task package.
In fact, all task packages could be made expandable to show the 
contained packages.
In addition to exploring the contents, it would be useful for installing 
part of a task package, by selecting the task and deselecting one or 
more contained packages.
(I realise this applies more to Rpmdrake.)

Since we are talking essentially about Mageia packages, this seems doable.

Note that, without considering this approach, if one wishes to show only 
"applications" and not other packages, in the current state of rpm 
packaging, that is a highly speculative process.
Just look at the suggested list of "orphan" packages, produced by Rpmdrake.
(At least in my case, it always includes a number of useful - and 
recently used - applications.)

In terms of presentation, it would be useful if a folded association 
group has an icon indicating if all/some/none of the contained packages 
are selected.
E.g., the filled/greyed/empty box used by the (Gnome) Nautilus file 
manager properties.

This folded view has been discussed in general terms on Mandriva 
lists/forums/bugzilla (I forget where) in the past, as well as recently 
in Mageia lists.

Note that there are many applications that are in a single package, 
except for shared libraries.  They, of course, will not be affected by 
this folding approach.
However, in most package groups (as used by Rpmdrake, rpm spec files), 
there is at least one application comprised of a considerable number of 
packages.  (See examples below.)

> How can we do for libs which are shared by many different applications ?
>    
It seems to me useful to keep shared libraries separate, as now.  They 
are generally now put in the Mandriva group system/libraries, or 
development/libraries.
Usually users will not want to look at such a package, unless it is not 
installed and specifically required by a third-party package (not in the 
Mageia distro).

> The idea sounds nice, but I'd like to see real examples, with answers to these questions :)
>    
Some examples of the number of packages in multi-package applications, 
by category :
(Packages with names starting the same word were assumed to be the same 
application.  Those with very different names were ignored.  So much of 
the core KDE packages would have been ignored, for example.)

_Applications_ (for third party packages)
-- LibreOffice, OpenOffice (official) = each about 60 packages

_Databases_
-- Freedict dictionnary = about 50
-- Gda +libgda = 14
-- mysql = 7
-- lbdb = 8
-- postgresq = approx 50
-- stardict = approx 180

_Office_ (Bureautique en français)
-- abiword = 4
-- celtx = 8
-- gnucash = 4
-- libopensync = 14
-- Openoffice (Go-oo version) = more than 170

_Communications_
-- barry* (scripts for blackberry) = 6
-- mgetty* = 5

_Development/other_
-- eclipse = 6
-- edos = 18
-- erlang* = approx 70
-- gambas = approx 44
-- gcc = 15
-- gcl = 9
-- ghc = 4
-- git = approx 10

_Development/C_
-- apache = 12
-- cross* (cross-compilers + preprocessors gnu) = 10
-- gcc = 8
-- libSDL = 12
-- libavahi = 15
-- libavc1394 (firewire) = 4

_Editors_
-- emacs + xemacs = approx 40
-- gedit = 5
-- vim = 5

_Education_
-- gcompris = 32
-- pysycache = 15

_System/kernel+hardware_
This category has many variations of the kernel and pilots, most 
containing numerous versions, compiled for several processors and uses.
If each variation were collapsed to one line, one only need expand the 
variation of interest to find the version one wishes to install, instead 
of having to scan many hundreds of lines
If collapsed, it looks like it would take less than 10% as many lines.

I'm sure that there are a lot of details needing more refinement.
> Regards
>
>    
>> For downloads/installation, using Rpmdrake (or equivalent) would be
>> preferable in most cases, as it could directly update the installed rpm
>> database.
>>      
> Installation from the website would not bypass media and rpm database. This would only be shortcuts. One thing the website can't know however is what packages are currently installed on your system, whereas rpmdrake can. I don't plan to find a way to make it know it for now (too much implications).
>    
That's good.  No point in unnecessarily complicating things.
>> However I think this project would be excellent for the other suggested
>> uses.
>>      
> Thanks, we'll try to do it right :)
>
> Regards
>
> Samuel Verschelde
>    

Great project.  Really like how you're reaching out for input, too.
(Even if my ideas end up being too complicated to implement :) )

BTW, I've been looking at the packaging tutorials, looking forward to 
getting started.

À bientôt

- André