From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110110/002043.html | 156 ++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110110/002043.html (limited to 'zarb-ml/mageia-dev/20110110/002043.html') diff --git a/zarb-ml/mageia-dev/20110110/002043.html b/zarb-ml/mageia-dev/20110110/002043.html new file mode 100644 index 000000000..c12a6696d --- /dev/null +++ b/zarb-ml/mageia-dev/20110110/002043.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] Importing RPM Groups + + + + + + + + + +

[Mageia-dev] Importing RPM Groups

+ andre999 + andr55 at laposte.net +
+ Mon Jan 10 01:43:01 CET 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Le dimanche 9 janvier 2011 10:49:19, Remy CLOUARD a écrit :
+>> Hi,
+>>
+>> I just imported the RPM Groups page into the wiki.
+>>
+>> I verified the list was complete with what rpmlint returns as valid RPM
+>> groups.
+>>
+>> Maybe some groups are obsolete, others could be created
+>>
+>> Proposal for removal:
+>> Graphical desktop/FVWM based (only one entry)
+>> Graphical desktop/Sawfish (only one entry)
+>>
+>> Proposal for creation:
+>> Development/Haskell
+>> Development/OCaml
+>> Graphical desktop/LXDE
+>> Networking/Chat (merge with Instant Messaging)
+>> Sound/Players (because listening to music and creating it is a very
+>> different thing IMHO)
+>> Sound/Editors
+>> Sound/Other
+>>
+>> WDYT ?
+>>
+>> Regards,
+>
+> I think groups may need a bigger rework than just those changes.
+
+Agreed.  Although it might not be a bad idea to start with these minor 
+changes.
+
+> To me,
+> package groups should be as close as possible as menu entries (for graphical
+> packages), but maybe that would be too few groups ?
+
+I have long thought this as well.
+And the menu system should accommodate console apps as well.  (Strictly 
+speaking it does, but generally you have to add the entries yourself.)
+Don't forget that the XDG menu system doesn't require a major GUI like 
+Gnome or KDE, or even LXDE.  It could be presented by a console app.  It 
+is basically just a tool to readily access (console or GUI) 
+applications.  All the more reason to try to harmonize (in both 
+directions) the presentation of packages for installation with the menu 
+system.
+
+> In fact, debian has some advance upon us on this, by the use of debtags. We
+> could maybe simplify grouping if we could put some information in tags rather
+> than in groups.
+
+Right.  With multiple tags, we can more finely classify packages.
+Particularly useful for such groups as network (internet in the menus), 
+where a package -- such as Mozilla Seamonkey -- can be email / irc / 
+file-transfer / www (as well as html editor) all at the same time. Those 
+distinctions remain useful when looking for a package with a particular 
+function.
+
+However the user package tools (such as mageia-app-db and rpmdrake) 
+should still present the packages by rpm group / tag, and not just rpm 
+group, in order to present a more manageable number of packages.
+Of course with this approach, a package with multiple tags will be 
+presented in more than one location.  (That used to happen with RedHat 
+installation cds.)
+
+There could also be a mechanism to not separately present a group/tag 
+catagory with less than a certain number of members (say 3), to avoid a 
+too balkanized presentation.  So if only 1 or 2 members, it is merged 
+with the parent category.  In the case of FVWM and Sawfish mentioned 
+above, they would be presented directly in the desktop GUI group.
+
+It occurs to me that there is essentially no difference between package 
+groups and tags, except that a package can have multiple tags.
+It might be useful to keep them separate on that basis - the package 
+being required (or allowed ?) to specify exactly one group, and 
+permitted to specify any number of tags.  Just a random thought.
+
+> I don't know if there are cross-distributions efforts to harmonize package
+> groups, but that would be an interesting subject to tackle in the upcoming
+> meeting in Nürnberg.
+
+Very good idea.  The more we can harmonize, the better for third-party 
+packages, the end-user, and Linux in general.
+(I'd like to see .rpm and .deb harmonized.)
+
+> More questions than answers :)
+
+Good questions lead to better answers :)
+
+> Regards
+>
+> Samuel Verschelde
+
+my 2 cents :)
+-- 
+André
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1