Re: TODO

[Jacob Meuser]

On Tue, Nov 16, 2004 at 12:00:09AM -0500, Daniel Reed wrote:
> On 2004-11-15T20:33-0800, Jacob Meuser wrote:
> ) their packages as soon as possible.  besides, it is arguable that
> ) libtool should be fairly well adapted to RedHat by default, the
> ) 1.5 branch has been around for a while now, and you are still
> ) shipping patches?
> 
> Until 1.5.10, we were actually patching 5 different areas of functionality ;)
> 
> The functionality provided by all but one of those patches has since been
> integrated into [upstream] Libtool.

great.  I'm not sure why you feel the need to mention that.  I never
made any claim to the contrary.

> 
> ) > (For that to make sense, keep in mind that, outside of the GNOME world, 
> the
> ) > autotools are used primarily at packaging time, not build time. Having a
> ) huh?  how can autoconf, or automake, or libtool be used at packaging
> ) time, and not build time?  and even if you could, why?
> 
> You do not need to have Autoconf installed to build an Autoconf-managed
> package. Similarly, you do not need to have Libtool installed to build a
> Libtool-managed library inside a libtoolized package, or to link against
> already-installed Libtool-built libraries.

yes, the autotools come with software.  that is, they are distributed
by many, many people.

> This is not true of, for example (to continue picking on it ;), PKGConfig,
> which needs at least a non-general-purpose, externally-installed executable
> (pkg-config) to function.

yes, it is distrubted by few.

> 
> ) besides, the biggest problem (assuming that OS/distros understand the
> ) reasons for not hacking autotools) is original distributors modifying
> ) libtool parts that are distributed with their software.  look and
> 
> In this case, bug reports going to the developer would be correct. The
> concern over having an operating system modify the Libtool it ships is that
> bug reports caused by the operating system's changes would incorrectly go to
> the developer, or to the GNU lists.

no, it is that when someone develops a package on a system that does
have the autotools installed, that package gets the autotools from
the autotools that were installed on that system.  therefore, if
the OS is distributing a hacked libtool, that package is shipping
a hacked libtool to every other system.

if making all packages that use libtool work by updating the libtool
package, that would be wonderful, but that is not the case :(

for example, libtool-1.5.10 works quite well on MyPreferredOS,
versions 1.4 <=> 1.5.6 though, have some serious issues.  I
installed the libtool-1.5.10 package on my MyPreferredOS system.
I still have to patch lots of packages that use libtool stuff.
in some cases this is not very easy, because they did not come
with a vanilla libtool to begin with.

now, who gets the error report?  the MyPreferredOS people?  the
libtool people?  the people distributing the package?  the people
distributing the libtool used to build the package?

usually, it goes to the MyPreferredOS people, who really have
nothing to do with it.  how often do you think it goes up
the line to the people who really need to know the problem?

OTOH, it is very easy to figure out if a package is putting bad
stuff into the package's .pc file, and I don't need to worry about
messing up things down the line by hacking the pkg-config binary
on my system.

-- 
<address@hidden>

> 
> -- 
> Daniel Reed <address@hidden>  http://people.redhat.com/djr/   
> http://naim.n.ml.org/
> I'd say some people have no lives, but I'm the one who's going to
> wallpaper his room in naim source in a few days. -- FalseName, EFnet #naim
> 
> 
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/libtool