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é
