[Mageia-dev] mageia sound tasks
andr55 at laposte.net
Sun Dec 19 11:24:33 CET 2010
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
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
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.
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
>> 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
Just try listing Mandriva meta/task packages, with rpm categories
active. I get 8 main categories, including sound. (A number of which
(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
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 :)
More information about the Mageia-dev