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/2011-December/010318.html | 141 +++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-December/010318.html (limited to 'zarb-ml/mageia-dev/2011-December/010318.html') diff --git a/zarb-ml/mageia-dev/2011-December/010318.html b/zarb-ml/mageia-dev/2011-December/010318.html new file mode 100644 index 000000000..e05ed7894 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-December/010318.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] Build-in or stand-alone module for X to support Y + + + + + + + + + +

[Mageia-dev] Build-in or stand-alone module for X to support Y

+ Kamil Rytarowski + n54 at gmx.com +
+ Sat Dec 10 14:41:30 CET 2011 +

+
+ +
W dniu 10.12.2011 14:11, Maarten Vanraes pisze:
+> Op zaterdag 10 december 2011 14:06:18 schreef Kamil Rytarowski:
+>> W dniu 10.12.2011 13:45, Maarten Vanraes pisze:
+>>> Op zaterdag 10 december 2011 13:12:52 schreef Kamil Rytarowski:
+>>>> Hello!
+>>>>
+>>>> Situation:
+>>>> A package X may have support for a package Y, by a module as a build in
+>>>> X or stand-alone package. All modules are possible to turn-on and to
+>>>> turn-off in a menu of X.
+>>>>
+>>>> And there is a discussion because there is no Y at all in Mageia.
+>>>> Person A says:
+>>>> - include the module, even if there is no Y in Mageia (and maybe never
+>>>> will be included), because an end-user can install Y from alternative
+>>>> source or compile it from sources; and don't add Suggests/Requires for Y
+>>>> in the package, because it's obvious that this is to support Y; also
+>>>> installing Y from alternative sources/self-compilation is much simpler
+>>>> than reinstalling X with support for Y
+>>>> Person B says:
+>>>> - don't include the module, because Y is a dependency for the module of
+>>>> X - and we don't ship broken packages that aren't self-contained; so it
+>>>> must be excluded from X or the nobody has package Y and maintain it
+>>>>
+>>>> Neither A nor B want to work with Y package.
+>>>>
+>>>> Who is right?
+>>> imho, if Y is wanted by some people, and X works more of less fine
+>>> without Y even if it's support is compiled, and sometimes a get-Y
+>>> package is fine.
+>>>
+>>> imho it's maintainer's preference, if maintainer is fine to also "support
+>>> the Y-module for X" even if depends on Y and Y is not allowed in mageia,
+>>> or even if Y is in nonfree... it's fine by me.
+>>> let's get into specifics:
+>> Well here there is no nonfree, demo, shareware, license issue. Just Y is
+>> yet another media-player. Importing Y is not a case for neiher A nor B.
+>> There is a question to include or not include a module (as an external
+>> package %{name}-module-mediaplayer_Y) for X. X is working perfectly
+>> without Y - Y is just adding some extra features. But the module for X
+>> is NOT working without Y. Well it's probably not breaking X, there will
+>> be an error message "error loading module-mediaplayer_Y".
+> you could find a way to configure it as disabled?
+Yes
+>   or move it to a subdir of sorts with a mention that if they do have Y that
+> they can put this file in the other dir.
+>
+> or... have a subpackage for this module and don't suggest it. plus have a
+> warning in it to say that it requires bla.
+>
+> so my vote is for A)
+I like the idea with URPMI warning at the install time, this would solve 
+the problem. "If you need Y support for X, we include the module, but 
+obtain Y at your own."
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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