Re: print-PLIST and options

[Aleksey Cheusov <vle%gmx.net@localhost>]

> Aleksey Cheusov <vle%gmx.net@localhost> writes:

 >>> tl;dr: I'm not hugely fussed if you want to add them, the patch for
 >>> automatic handling looks reasonable at first glance, but if the work
 >>> results in any broken package updates I will be very very sad.
 >>
 >> I already implemented proposal by Thomas Klausner. That is, print-PLIST
 >> prints ${PLIST.nls} only is option "nls" already exists. So this patch
 >> doesn't break anything.

> I think the question is not about the patch, but about the practice of
> adding nls to vast numbers of packages, and having done so without
> proposing and discussing.

My personal motivation for adding "nls" option is the following.  I
often use pkgsrc in unprivileged mode on systems where I have only
unprivileged shell account. So, I have to periodically run
pkg_rolling-replace or "bmake install/replace" manually in order to keep
packages up-to-date.  These machines are often very slow, not that they
are from embeddable world, but they are slow. As a result rebuilding all
packages takes significantly more time than it is really needed.  So, I
disable everything I don't need, in particular "nls" option. And I am
not alone here. Someone in this thread already mentioned embedded systems
with very limited resources.

Also, pkgsrc breaks something from time to time and extra dependencies
increases risk or such breakages, especially on non-NetBSD systems (this
is exactly my case!). So, the less extra-dependencies, the less risk to
see build failures. Fixing pkgsrc on OpenBSD, Solaris-10, Interix
etc. is very interesting process but it's not always possible.

About risks. I think once "nls" option is added to the package, the
chance of its brackage in future is minimal, if correct PLIST is
autogenerated. That's why proposed the patch for print-PLIST -- to
minimize such risk globally, not on per-package basis.