[Mageia-dev] mageia sound tasks

[andre999]

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é