Re: Bug#38544: #38544: Gettext solution (Was: Re: gettext packages)
> On Wed, 2 Jun 1999, Julian Gilbey wrote:
>
> > > Why don't you report "this package should be splitted because it is
> > > too large and contains things which are not normally useful" as a bug
> > > against libc6-dev?
> >
> > Because libc6-dev is a development package anyway, and is named as
> > such. No desire to compile => no need for libc6-dev; desire to
> > compile => need for libc6-dev.
>
> I think you have a very simplistic view of what a Debian package *may* be.
> "A package should be either 100% a development package or else 0%".
> I don't think this has to be the case.
You're right -- it doesn't. But that's not a reason not to split
gettext. Would you advocate merging libfoo and libfoo-dev into one
package, as someone who wants to compile something depending upon
libfoo will need the -dev package?
> I would say "Desire to use (directly or indirectly) any of the tools in
> the gettext package -> need gettext. No desire to use (directly or
> indirectly) any of the tools in the gettext package -> no need gettext.
Desire to use libc6 requires the whole of libc6 to be installed?!
> > Further, Joe User downloads some
> > package which he wants to use and it requires compilation. Just so
> > happens that the authors of the package have decided for one reason or
> > another to make the binary statically linked. ("Installation
> > instructions: type ./configure; make") How should Joe User understand
> > why only having libc6-headers or whatever it would be called and not
> > libc6-static makes his compilation fail?
>
> Let's follow Joe User's example:
>
> Suppose gettext is splitted into gettext and gettext-dev ("gettext-dev"
> because you insist that a development package needs to be named
> whatever-dev).
I don't remember insisting that. gettext-base and gettext would be
fine too.
> Joe User wants to compile and install a package whose README file says
> "you need gettext to compile this package".
>
> Joe User would then complain "Ok, I have the gettext package installed,
> but it still does not work. Why?".
>
> [ What should I answer to him if Joe User asks me about this?
> "Because Julian Gilbey thought it was a bug not to split it"? ].
So name the packages gettext-base and gettext. Problem solved. (BTW,
do any Debian packages require gettext to be installed in order to use
them?) And you could, of course, write something appropriate in the
documentation for the packages to explain this.
> > So I'm actually less
> > inclined to ask for libc6-dev to be split than I was yesterday.
>
> Well, I guess it is perfectly possible that there are actually more
> packages needing gettext for compilation than packages needing the static
> libraries in libc6-dev.
I would guess that most packages downloaded from wherever which
require gettext will have it included in the tar bundle. This also
means, you see, that they can tweak the Makefile.in as necessary. See
what is done in libc6/glibc2 for example. But I have done no surveys,
so I couldn't tell you for certain. In potato, the only packages
currently depending upon gettext are: boot-floppies and pointerize,
both most definitely development tools. (Building the boot-floppies
is not for the feint-hearted, as I once discovered!) A couple of
packages suggest it. I don't think this is much of a problem.
> Does this mean libc6-dev contains part that should not be of standard
> priority? Do I advocate for the splitting of libc6-dev? Not at all. What I
> mean is that if you advocate for the splitting of gettext because of
> "space concerns", you should probably advocate for the splitting of many
> other packages before this one. I'm just asking you a little of
> consistency.
Space concerns are critical where boot floppies are concerned. I have
no idea whether even the reduced version I propose would fit. But I
sure know that 950k or whatever won't. But also, as it is even said
in the gettext docs:
Those four packages are only needed to you, as a maintainer; the
installers of your own package and end users do not really need
any of GNU `m4', GNU Autoconf, GNU `gettext', or GNU `automake'
for successfully installing and running your package, with messages
properly translated. But this is not completely true if you
provide internationalized shell scripts within your own package:
GNU `gettext' shall then be installed at the user site if the end
users want to see the translation of shell script messages.
There is clearly a tension here between gettext being most definitely
a maintainer's tool, and at the same time necessary for users if they
want i18n of shell scripts. What I am advocating, and the upstream
author will do this if I provide a clean patch to do so, is a
splitting of the user and maintainer parts.
> > Of
> > course, if you don't want to do any compiling, you can just get rid of
> > the libc6-dev package. The only packages which depend upon or
> > recommend libc6-dev are development packages themselves, and
> > pine-diffs. (At least in slink, that is, haven't checked out potato.)
> >
> > On the other hand, gettext is not the same. There is a very clear
> > distinction between the user's part (/usr/bin/gettext) and the
> > developer's part (/usr/share/gettext/* and its accompanying
> > documentation).
>
> The user part is not limited to the /usr/bin/gettext binary (those 17k you
> like to mention so much). A binary within a Debian package needs a
> manpage, a copyright file, two changelog files, info documentation, and
> (in the case the binary has been internationalized, all the message
> catalogs for it). Sorry but this is much more than 17k and will not help
> to reduce the size of the package in a significant way.
Firstly, have a look at the perl-base package. It has precisely one
piece of documentation: the copyright notice. I think that if the
intention is to make a tiny package potentially suitable for the boot
discs, then we could get by with little more than this.
But assume that you want a "proper" package out of it. Let's go
through the things that might be needed by a user of gettext purely
within the context of using it within existing shell scripts.
Manpage: point to undocumented(8) as it is, indeed, undocumented. Or
put in your manpage: 385 bytes. Copyright file: this package is under
the GPL, so the copyright file *could* be very small if space is at a
premium. At present, it's about 1.5k. Changelog: The Debian
changelog will be small, presumably. (It's currently about 2k.) The
upstream changelog mostly refers to the rest of the gettext package
and is, essentially, irrelevant to /usr/bin/gettext. Next: info
files: they would not be needed in this package as they do not
describe the gettext program. Finally, the big one: message
catalogues. At present, they account for about 220k. But as I have
said before, if they are reduced to only include what is necessary for
gettext, you will be down to about 50k. So if we have everything
needed, I make it about 70k, say plus 10k for .deb packaging stuff.
(And that's installed size.) That's less than 10% of the size of the
current package. I think that this *is* a significant saving.
> I'm worried about the fact that you have intentions to split the message
> catalogs for the gettext package in two.
Why would that be a problem?
> This does not makes things better. Do you want the /usr/bin/gettext to
> remain undocumented in the base system or do you plan to split the manual
> in two too? None of this seems reasonable to me.
/usr/bin/gettext itself currently has no documentation beyond the
output of gettext --help.
I don't understand why you are so opposed to this idea.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Reply to: