[Mageia-dev] mageia sound tasks

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
+>> 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é
+