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

[Maarten Vanraes]

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