On Thu, Feb 03, 2005 at 12:09:20AM +0100, Santiago Vila wrote: > On Wed, 2 Feb 2005, Denis Barbier wrote:
> > You are running dpkg-shlibdeps not only against usr/bin/* but also > > usr/lib/gettext/*, and the dependency on libgcj4 comes from > > gnu.gettext.DumpResource and gnu.gettext.GetURL which are not required to > > run gettext tools: I did not have a close look at gnu.gettext.DumpResource, > > but gnu.gettext.GetURL (which triggered #244215) is only used by > > /usr/lib/gettext/urlget. Now have a look at gettext-tools/src/urlget.c > > and you will see that the fetch() command tries several scenarios to > > download a file from an URL. For all except gnu.gettext.GetURL, it > > first checks whether the tool seems to work (here nothing is sent do > > stdout or stderr), and then perform the download with normal stdout and > > stderr so that problems can be reported. > > So #244215 is due to the fact that gnu.gettext.GetURL is run without > > first checking whether it can run. A fix is to let gnu.gettext.GetURL.main > > handle a --version option, and treat gnu.gettext.GetURL like other > > alternatives in the fetch() function. I will provide a patch if you are > > willing to go this way. > Well, libgcj is 8MB large and wget is just 1456K large (which compared > to gettext itself, it's small). I think we could just remove the "first try" > from urlget.c, and make gettext to depend on wget | lynx | curl. FWIW libgcj also pulls in libgcj-common for another 4MB, so it's really something like 12MB vs. 1456K. :) > > > Considering that not everybody who uses debhelper uses po-debconf, > > > the logical thing to do here, IMHO, to preserve granularity, would > > > have been not to add such dependency, but instead require that > > > packages which need po-debconf (a minority of them) add it > > > to their build-depends. > > The same argument applies against msginit, so you can replace this > > dependency by > > Recommands: libgcj4 | wget | lynx | curl > > or even drop the first one. Adding a w3m alternative in urlget.c would > > also be nice since this package is now of standard priority. > The first one (libgcj4) would disappear as soon as I drop gcj from the > build depends. There is already another java compiler in the build-depends, > and that's enough to create libintl.jar in gettext-base. > The good thing is that when gcj is not present, another .jar is > created called gettext.jar, which I think (have to check) it has the > functionality of gnu.gettext.GetURL and gnu.gettext.DumpResource > (the last one being required to develop java applications which use > gettext, I think). > As opposed to po-debconf in debhelper, I do not consider users of > msginit to be a minority among the users of gettext. The gettext > package is used by programmers (which I think are a minority) and > translators (which I think they are the big group of users). > As msginit is used by translators, I would much prefer a dependency on > "wget | lynx | curl" so that it always work. > So here is the current plan: > * Drop gcj from build depends. > * Keep jikes-classpath in the build depends. > * Include gettext.jar in the gettext package. > * Remove the "first try" from urlget.c. > * Add a dependency on "curl | wget | lynx" to gettext. > (curl is 220Kb large, I think everybody will be happy to use this > instead of libgcj4). > * People who want to develop java applications which use gettext > should do so using a java virtual machine for gettext.jar to work. > I can add a note to README.Debian similar to the already existing > one for autopoint and cvs. > Does this look good enough to consider this issue resolved? I think this change is a positive thing. Thank you for considering the concerns that were raised. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
