[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TODO
From: |
Gary V. Vaughan |
Subject: |
Re: TODO |
Date: |
Fri, 19 Nov 2004 06:59:00 +0000 |
User-agent: |
Mozilla Thunderbird 0.9 (Macintosh/20041103) |
Bob Friesenhahn wrote:
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
It wouldn't be at all difficult to have 'libtoolize --ltdl
--disable-nls' install a non-internationalised libltdl minus message
catalogues into a parent package. But yes, we would have to take care
to do it carefully. An improved post-2.0 testsuite should help there :-)
There are oodles of dangers here. For example, a package distribution
maintainer for a particular OS may not agree with the package
developer's choices so he will install his own libltdl with the extra
message catalogues. This could make things very confusing/difficult for
the package developer. There is already plenty of confusion caused by
package distribution maintainers who replace the existing libtool in a
package with one that they prefer.
So you think it's a problem that (a) the project maintainer can choose
to ship a non-internationalised libltdl with their project, and then
(b) a system integrator chooses to link against an internationalised
libltdl?
Any sensible project maintainer will ship i15d libltdl with their i15d
package, or non-i15d libltdl with their non-i15d package. If some-one
chooses to mix and match, they are beyond our help!
If the project maintainer stupidly `libtoolize --ltdl --disable-nls'
installs libltdl in their i15d package, and a systems integrator chooses
to fix it by relibtoolizing --enable-nls to match the parent project,
that's a good thing.
If the integrator stupidly relibtoolized with a different option when
the project maintainer shipped the correct libltdl, he is beyond our
help too.
On the flip side, the package developer may choose to distribute an
internationalized libltdl, which causes new issues for end-users and
package distribution maintainers.
I fail to see the problem... but it is 2am...
Cheers,
Gary.
--
Gary V. Vaughan ())_. address@hidden,gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
- TODO, Peter O'Gorman, 2004/11/09
- Re: TODO, Gary V. Vaughan, 2004/11/09
- Re: TODO, Ralf Wildenhues, 2004/11/09
- Re: TODO, Gary V. Vaughan, 2004/11/09
- Re: TODO, Daniel Reed, 2004/11/10
- Re: TODO, Gary V. Vaughan, 2004/11/10
- Re: TODO, Bob Friesenhahn, 2004/11/10
- Re: TODO,
Gary V. Vaughan <=
Re: TODO, Peter O'Gorman, 2004/11/10
- Re: TODO, Gary V. Vaughan, 2004/11/10
- Re: TODO, Scott James Remnant, 2004/11/10
- Re: TODO, Ralf Wildenhues, 2004/11/10
- Re: TODO, Gary V. Vaughan, 2004/11/10
- Re: TODO, Ralf Wildenhues, 2004/11/10
Re: TODO, Scott James Remnant, 2004/11/10
Re: TODO, Scott James Remnant, 2004/11/10