pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/databases



Le 2019-10-25 15:27, Greg Troxel a écrit :
Takahiro Kambe <taca%NetBSD.org@localhost> writes:

In message <C1FA39BA-D270-44A8-8306-88C293AA0068%NetBSD.org@localhost>
        on Fri, 25 Oct 2019 07:29:25 +0200,
        Adam Ciarciński <adam%NetBSD.org@localhost> wrote:
But if most people prefer having locales by default, I can move nls option to PKG_SUGGESTED_OPTIONS.

IMHO the package must be as complete as possible, so people can download a binary package and do not have to recompile it manually when they need the NLS strings, for example.
I agree.

Please, turn the nls option on.
+1.

And, procedurally:

  adding an option for something that's already included and making it
  default on more or less  does not need discussion.  Same with adding
an option for something that's not included and making it default off.

  turning off things by default generally needs discussion.



'make nls support optional' is not an adequate commit message, because
it leaves out the critical point of whether the commit turns it off, vs,
leaves it as it was.

  From: Frédéric Fauberteau <triaxx%NetBSD.org@localhost>

  I think nls is not an indispensable feature to make a package working
  well. If I build packages with PREFER_PKGSRC=yes or if gettext is not
  available on the system, it removes dependencies to devel/gettext-lib
  and converters/libiconv (that is a poor implementation). If I pbulk a
  set of packages for servers, I get a /usr/pkg subtree with no
  /usr/pkg/share/locale directory. But If a want package for my laptop
  or desktop, I build them with PKG_DEFAULT_OPTIONS=nls.

As Adam said, defaults are important for binary package users, and we
weigh usefulness and how many people want something vs the pain of
dependencies.   Given that many things need gettext/iconv, the pain of
depending on them is quite small, and people view postgresql w/o nls as
deficient.  So this seems like a really obvious case to be default on.

Reading your rationale, I see you have a case where you want to avoid
it, but it feels like a special case, rather than majority.

Thanks Greg for this clear explanation.

'make nls support optional'
Sure

Reading your rationale, I see you have a case where you want to avoid
it, but it feels like a special case, rather than majority.
I can easily avoid it by PKG_DEFAULT_OPTIONS= -nls, it is not a problem for me since I build my own subset of packages. So, I am interested in the opinion of the majority.




Home | Main Index | Thread Index | Old Index