shells/bash and the libiconv dependency mess

[Alex Goncharov]

,--- You/Jeremy (Mon, 16 Aug 2010 23:01:14 -0700) ----*
| On 2010/05/11, ehaupt committed the following patch:
| 
| http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/files/patch-Makefile.in
| 
| And bumped PORTREVISION (from 0 to 1) in the Makefile.  This
| unconditionally made bash require libiconv, and the only justification
| is "fix statically linked version".
| 
| Those of us who use WITHOUT_NLS or who do not have libiconv already on
| their systems (from another port) immediately notice the problem (bash
| will no longer build):
| 
| http://www.freebsd.org/cgi/query-pr.cgi?pr=147747
| http://www.freebsd.org/cgi/query-pr.cgi?pr=148329
| http://www.freebsd.org/cgi/query-pr.cgi?pr=149218
| 
| Three months goes by and finally something is committed to fix the
| problem on 2010/08/06.  Except the fix doesn't make any sense; all it
| does is make libiconv a mandatory dependency (USE_ICONV):
| 
| http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/Makefile#rev1.123
| 
| This, of course, means that WITHOUT_NLS is broken and doesn't work as
| it's supposed to, since libiconv is now a mandatory requirement (it
| doesn't need to be):

Mine is 147747, and I say (in http://www.freebsd.org/cgi/query-pr.cgi?pr=147747):

>>> It would be ideal to be able to exclude libiconv from the build and
>>> dependency, subject to a certain make variable setting, but this seems
>>> to be difficult to do without the port surgery available only to the
>>> port maintainer, so at least let's register the libiconv dependency
>>> correctly, so that the installation from a package results in a
>>> workable `bash'.

So, I agree with you.  What was suggested in my PR was the minimum to
make the dependency list honest -- not to depend on libiconv would be
much better.

| # make WITHOUT_NLS=true all-depends-list
| /usr/ports/devel/bison
| /usr/ports/converters/libiconv
| /usr/ports/devel/m4
| /usr/ports/devel/libtool22
| 
| Why was this done the way it was?  patch-Makefile.in should be removed
| and instead replaced with a REINPLACE_CMD that handles the conditionals
| (WITH_STATIC_BASIC, WITHOUT_NLS, etc.) in a more clean manner.
| 
| And where are the details of the supposed "statically linked version"
| problem?
| 
| Sorry if I sound angry, but this whole situation is a mess, and
| shells/bash is a very important port.

Agree here, too -- can't live without it.

| If someone wants me to put my money where my mouth is and go + clean
| it up I'll be happy to.  Testing all the different quirk
| combinations really isn't that complex.

I *definitely* want it -- your anger is justified.  Bash is an
essential component of FreeBSD and should be given all the care and
attention possible.

I could help with testing/maintaining the bash port, too (not until
the end of August, though).  But I am of the opinion, OTOH, that's
it's a port maintainer responsibility to drive the effort.

Plainly put: if the current maintainer doesn't have time or desire to
maintain this critical port properly, will you (the maintainer) kindly
release your maintainership to be passed over to somebody who will?

Making mistakes is completely OK, in my mind; letting the
simple-to-fix issue to be marinated for two months, since the first
report:

------------------------------
  147747:
   Open: Wed, 09 Jun 2010 23:34:12 -0400
   Closed: Fri Aug 06 10:49:57 CEST 2010
------------------------------

is not OK (IMHO).

Thank you, Jeremy!

-- Alex -- alex-goncharov at comcast.net --