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é
