devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

[Dmitry Marakasov]

* Peter Pentchev (roam at ringlet.net) wrote:

> > This is definitely a bug, so better send-pr for this issue not to be
> > lost while we're in freeze.
> What I mean is the following scenario:
> - libfoo uses libtool for its build
> - libfoo depends on libbar which depends on GNU sed
> - during libfoo's build, libbar is built, thus gsed is installed
> - during libfoo's build, libtool detects gsed installed and "remembers" it
No, as <previously built> libtool package will be used, which doesn't
use gsed for sure.
> - in libfoo's binary package, there is a shell script that uses "gsed",
>   because libtool "knows" gsed is present on the system
> - an unsuspecting user installs the libfoo binary package without previously
>   building libbar
> - the unsuspecting user gets a shell script that tries to run "gsed" and
>   fails.
...
> If libtool may put "gsed" into libfoo's binary package, this should be
> fixed before the freeze.  If libtool only uses "gsed" during libfoo's
> build, then it is not a critical problem.
Neither seem to be the case for package building.

> Of course, if Dmitry is more familiar with libtool than I am, and he
I am most likely not,
> knows that libtool does not leave any such files, then I've just wasted
> everybody's time with unneeded idle speculation, for which I apologize :)
but my vision is that the problem will only show itself if you build
libtool with gsed installed and then deinstall gsed. Thus, you'll
end up with defunct libtool and all ports which have
USE_AUTOTOOLS=libtool:15 will fail to build.

Since this doesn't affect package builds, I don't this this is serious
enough to fix duing freeze. But still to be fixed :)

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru