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

Sat Dec 10 14:48:32 CET 2011

Op zaterdag 10 december 2011 14:41:30 schreef Kamil Rytarowski:
+> 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."
+
+look at other packages, like mysql, they generate a README.install.urpmi file 
+which show this text in rpmdrake
+