Attn: cygport maintainer [was: Re: Libtool 2.2.2]

[Charles Wilson]

Brian Dessent wrote:
> Angelo Graziosi wrote:
> 
>> and if cygport depend on libtool1.5, how can the user who needs
>> libtool2.2 install it without uninstalling libtool1.5+cygport+...?

I think cygport should remove its requires: libtoolx.y from its 
setup.hint.  It currently lists that because the default
   src_compile()
implementation calls
   cygautoreconf()
which itself checks the to-be-built packages' configure.[in|ac] and 
checks that various autotools are installed. It doesn't do anything 
special with regards to libtool, except:

   if WANT_AUTOCONF=2.1
     if configure.[in|ac] contains "A[CM]_PROG_LIBTOOL"
       issue a warning that libtool1.5 is incompatible with autoconf-2.13

CYGPORT CODE CHANGE:
Now, with libtool2.2, that test needs to also check for LT_INIT, as well 
as the older A[CM]_PROG_LIBTOOL macros.  Furthermore, you can still use 
cygport even without libtoolx.y installed:

write your own src_compile() method that doesn't call cygautoreconf

"export LIBTOOL=no" before calling cygautoreconf (or "before" calling 
the default src_compile)

So, really, libtoolx.y is not a requirement of *cygport*, per se, but is 
a build-depends of whatever you are trying to use cygport to build.

> They would have to manually override the warning of setup in order to
> install libtool2.2+cygport.  
> 
>> If one install libtool2.2 without removing anything, it overwrite
>> libtool1.5, and I think this is a little confusing.

And will break things, as the OP pointed out.

> Yes, it's not great but it's the best we can do.  Feel free to suggest
> something less confusing, subject to the following constraints:
> 
> - Both libtools can't exist on a system at once
> - Setup cannot express a mutual exclusivity, nor can it cause any
> package to be deselected
> 
> The only thing I can think of is to wrap both libtool packages in a
> postinstall wrapper 

Ugh. No, thanks.

> In the short term it would probably make more sense to simply drop
> libtool from the cygport 'requires:' and instead document somewhere that
> you need one or the other installed.

But you don't, really. See above.

> Cygport could potentially drop
> something in profile.d to do this check and alert the user if
> something's wrong, however I dislike the idea of penalizing every
> cygport user with yet another task at the start of every login shell. 

CYGPORT CODE CHANGE:
No, instead cygport itself, inside cygautoreconf(), could perform that 
check.  That is, if LIBTOOL != "no", and configure.[ac|in] contains 
LT_INIT|A[CM]_PROG_LIBTOOL, then
   if ! check_prog libtool1.5 && !check_prog libtool2.2
     issue error message about missing libtool

> It could also be possible for a cygport postinstall to check for libtool
> and only if not found drop something in profile.d that displays a
> warning.

No need to mess with profile.d; cygport itself can do the check. That 
way, only cygport users, when actually using cygport, are "penalized" by 
checking for libtool presence.

> Yet another option would be to fix setup to allow more complex
> dependencies to be expressed, but that's even more complicated as a)
> SHTDI and b) there's always going to be users not using the latest
> setup.exe even months/years after a new version is released.

Yep, to both.

In any case, there is no need to wait for the various modifications to 
cygport. We can (and should) remove the libtool1.5 require: from 
cygport's setup.hint immediately. (Where "immediately" means "give 
Yaakov a decent interval to chime in on this thread...")

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/