Michael scherer a écrit :
On Sat, Dec 18, 2010 at 10:03:36AM +0100, SaschaS wrote:
So I see basically that we need a guidline on how mageia deals with Spinoffs
first.
It would probably be better to avoid spinoffs. The special interests -
sound in this case - would generally be followed by users that have
otherwise more or less average Mageia user interests.
In other words, they would generally want in other respects the standard
Mageia distro.
So instead of having a less well-maintained spinoff, wouldn't it be
better to have a few extra specialized packages in the contrib (or
equivalent) repositories of Mageia ?
I think so.
<aside>
Of course there are those that want to eliminate a separate set of
contrib equivalent repos - but such a separation does seem useful, as in
this case.)
</aside>
If all task are in the repos, I can understand those who say that there are
to many task.
The problem is not that there is too much more than the consequence of the
high number of task-*.
rpmdrake, who is the main consumer of task-* rpm
convention, show all of them as 1 single list. So basically, with lots of tasks-
rpm, you just have a big unsorted list of category. Obviously not good for
endusers.
While it would be useful to group task into sound category, for the moment,
we cannot.
Why not ?
Unless of course there are plans to abandon Mandriva's rpm categories.
Using these rpm categories, of which sound is one, separation is handled
nicely.
Just try listing Mandriva meta/task packages, with rpm categories
active. I get 8 main categories, including sound. (A number of which
have subcategories.)
(I don't know if it is "meta" or "task" in English.)
As well, if the folding proposals for mageia-app-db are carried to
rpmdrake (as I hope they will be), then task unfolding/expanding will
allow users to more easily see the real packages referenced by a task
package.
And hopefully allow selective installation of these referenced packages.
It seems that this will make the use of task packages more attractive.
One way would be to encode this information in the name ( ie, decide
that task-sound-foo and task-sound-bar are part of the sound category ).
No need to encode this into the name (unless one wants to).
I am not sure that using the name for this is a good idea. It is quite poor,
in term of metadata, and that's still a tree structure, while may a tag based
one may be better ( like Debian do, for example ).
More ever, it doesn't make much sense to have task-lamp-* task-nagios and
task-kde4
at the same level, they are not destined at the same public.
Exactly why there are rpm categories. "Development" is not destined to
the same public as "Sound" or "Education".
Not to mention that installing rpm is ust half of the solution, configuration is
the other one. While we can to some extend push configuration in the rpm, there
is some that we cannot do reliably ( like adding a user to a group ).
So maybe a wizard is a better solution than using a rpm that does magically
everything.
Good point. Of course a task rpm could well install a configuration tool.
my 2 cents :)
André
