diff options
Diffstat (limited to 'zarb-ml/mageia-discuss/20101109/002980.html')
| -rw-r--r-- | zarb-ml/mageia-discuss/20101109/002980.html | 264 |
1 files changed, 264 insertions, 0 deletions
diff --git a/zarb-ml/mageia-discuss/20101109/002980.html b/zarb-ml/mageia-discuss/20101109/002980.html new file mode 100644 index 000000000..f2bc4c9b3 --- /dev/null +++ b/zarb-ml/mageia-discuss/20101109/002980.html @@ -0,0 +1,264 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-discuss] Introducing mageia-app-db + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Introducing%20mageia-app-db&In-Reply-To=%3C4CD8D4C0.3010100%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002989.html"> + + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-discuss] Introducing mageia-app-db</H1> + <B>andre999</B> + <A HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Introducing%20mageia-app-db&In-Reply-To=%3C4CD8D4C0.3010100%40laposte.net%3E" + TITLE="[Mageia-discuss] Introducing mageia-app-db">andr55 at laposte.net + </A><BR> + <I>Tue Nov 9 05:57:36 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="002989.html">[Mageia-discuss] Kernel handling +</A></li> + + <LI> <B>Messages sorted by:</B> + <a href="date.html#2980">[ date ]</a> + <a href="thread.html#2980">[ thread ]</a> + <a href="subject.html#2980">[ subject ]</a> + <a href="author.html#2980">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Samuel Verschelde a écrit : +><i> +</I>><i> Le vendredi 5 novembre 2010 06:38:14, andre999 a écrit : +</I>><i> +</I>>><i> As far as the question of application/package view goes, folding entries +</I>>><i> (as in Rpmdrake groups or Nautilus) which expands to multi-line would be +</I>>><i> nice. +</I>>><i> That way complex packages like Openoffice or Firefox could be folded +</I>>><i> into 2 or 3 lines. +</I>>><i> (1 for localisation, another possibly for optional modules, another for +</I>>><i> core modules.) +</I>>><i> Now Firefox is more than 100 packages. +</I>>><i> This sort of suggestion has been made for Rpmdrake. +</I>>><i> The advantage of this approach is that the minimised view could be the +</I>>><i> default, and at any time it can be expanded to show all packages, +</I>>><i> without any configuration settings. +</I>>><i> +</I>><i> I'm not against, however how can we define those groups ? Is there a way to automate it ? Is it necessary to define it manually (and so to maintain it so have maintainers of these groups definitions) ? +</I>><i> +</I>First of all, the idea is to continue to use Mandriva-like categories +for the packages, as in Rpmdrake. So we associate packages within these +larger categories. + +The basic idea is to establish a hierarchy of views for multi-package +applications. +These associations should be designated according to guidelines, which +are yet to be established, according to the best judgement of the packager. + +Otherwise I don't see how we can arrive at consistant and useful +associations, especially if being used by different applications, like +Rpmdrake and your (very interesting and useful) project. It is +important that such applications are able to discern these associations, +in order to display them. + +First it will be useful to look at the different types of associations : +1) Where usually all of the associated packages would be installed, such +as core packages of OpenOffice or Go-oo or LibreOffice. + +2) Where usually only one - or a few - of the associated packages would +be installed, such as localisations. + +3) Something in between, such as optional extensions for Firefox + +Probably the best way to associate packages is to use an additional tag +in the package spec file. In addition to the package "name" tag, have +an additional tag, let's call it "subname", for the associated package. +(Since I am only beginning to familiarise myself with the details of rpm +packaging, including the spec file, I don't know if an equivalent a tag +already exists. If not, I hope that there is no problem creating one.) + +For the first type of association described above, the key package would +have the "name" tag but not a "subname". The other core packages would +have the same "name" tag, being differentiated by a "subname" tag. + +For the other types of associations, there would be a meta package with +a distinct "name" tag; all the real packages using this distinct "name" +plus a differentiating "subname". +So an application could have its various packages divided into as many +groups as desired, with all but the core group subsidiary to a meta +package. I would suggest that generally one would not want more than 3 +groups for a large application, but this grouping would be left to the +packager. +As well, related but different applications could be grouped by this +method, using a task package. +In fact, all task packages could be made expandable to show the +contained packages. +In addition to exploring the contents, it would be useful for installing +part of a task package, by selecting the task and deselecting one or +more contained packages. +(I realise this applies more to Rpmdrake.) + +Since we are talking essentially about Mageia packages, this seems doable. + +Note that, without considering this approach, if one wishes to show only +"applications" and not other packages, in the current state of rpm +packaging, that is a highly speculative process. +Just look at the suggested list of "orphan" packages, produced by Rpmdrake. +(At least in my case, it always includes a number of useful - and +recently used - applications.) + +In terms of presentation, it would be useful if a folded association +group has an icon indicating if all/some/none of the contained packages +are selected. +E.g., the filled/greyed/empty box used by the (Gnome) Nautilus file +manager properties. + +This folded view has been discussed in general terms on Mandriva +lists/forums/bugzilla (I forget where) in the past, as well as recently +in Mageia lists. + +Note that there are many applications that are in a single package, +except for shared libraries. They, of course, will not be affected by +this folding approach. +However, in most package groups (as used by Rpmdrake, rpm spec files), +there is at least one application comprised of a considerable number of +packages. (See examples below.) + +><i> How can we do for libs which are shared by many different applications ? +</I>><i> +</I>It seems to me useful to keep shared libraries separate, as now. They +are generally now put in the Mandriva group system/libraries, or +development/libraries. +Usually users will not want to look at such a package, unless it is not +installed and specifically required by a third-party package (not in the +Mageia distro). + +><i> The idea sounds nice, but I'd like to see real examples, with answers to these questions :) +</I>><i> +</I>Some examples of the number of packages in multi-package applications, +by category : +(Packages with names starting the same word were assumed to be the same +application. Those with very different names were ignored. So much of +the core KDE packages would have been ignored, for example.) + +_Applications_ (for third party packages) +-- LibreOffice, OpenOffice (official) = each about 60 packages + +_Databases_ +-- Freedict dictionnary = about 50 +-- Gda +libgda = 14 +-- mysql = 7 +-- lbdb = 8 +-- postgresq = approx 50 +-- stardict = approx 180 + +_Office_ (Bureautique en français) +-- abiword = 4 +-- celtx = 8 +-- gnucash = 4 +-- libopensync = 14 +-- Openoffice (Go-oo version) = more than 170 + +_Communications_ +-- barry* (scripts for blackberry) = 6 +-- mgetty* = 5 + +_Development/other_ +-- eclipse = 6 +-- edos = 18 +-- erlang* = approx 70 +-- gambas = approx 44 +-- gcc = 15 +-- gcl = 9 +-- ghc = 4 +-- git = approx 10 + +_Development/C_ +-- apache = 12 +-- cross* (cross-compilers + preprocessors gnu) = 10 +-- gcc = 8 +-- libSDL = 12 +-- libavahi = 15 +-- libavc1394 (firewire) = 4 + +_Editors_ +-- emacs + xemacs = approx 40 +-- gedit = 5 +-- vim = 5 + +_Education_ +-- gcompris = 32 +-- pysycache = 15 + +_System/kernel+hardware_ +This category has many variations of the kernel and pilots, most +containing numerous versions, compiled for several processors and uses. +If each variation were collapsed to one line, one only need expand the +variation of interest to find the version one wishes to install, instead +of having to scan many hundreds of lines +If collapsed, it looks like it would take less than 10% as many lines. + +I'm sure that there are a lot of details needing more refinement. +><i> Regards +</I>><i> +</I>><i> +</I>>><i> For downloads/installation, using Rpmdrake (or equivalent) would be +</I>>><i> preferable in most cases, as it could directly update the installed rpm +</I>>><i> database. +</I>>><i> +</I>><i> Installation from the website would not bypass media and rpm database. This would only be shortcuts. One thing the website can't know however is what packages are currently installed on your system, whereas rpmdrake can. I don't plan to find a way to make it know it for now (too much implications). +</I>><i> +</I>That's good. No point in unnecessarily complicating things. +>><i> However I think this project would be excellent for the other suggested +</I>>><i> uses. +</I>>><i> +</I>><i> Thanks, we'll try to do it right :) +</I>><i> +</I>><i> Regards +</I>><i> +</I>><i> Samuel Verschelde +</I>><i> +</I> +Great project. Really like how you're reaching out for input, too. +(Even if my ideas end up being too complicated to implement :) ) + +BTW, I've been looking at the packaging tutorials, looking forward to +getting started. + +À bientôt + +- André + +</PRE> + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002989.html">[Mageia-discuss] Kernel handling +</A></li> + + <LI> <B>Messages sorted by:</B> + <a href="date.html#2980">[ date ]</a> + <a href="thread.html#2980">[ thread ]</a> + <a href="subject.html#2980">[ subject ]</a> + <a href="author.html#2980">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-discuss">More information about the Mageia-discuss +mailing list</a><br> +</body></html> |