Red Hat Bugzilla – Bug 300161
split gettext into base, libraries, gettext, devel
Last modified: 2009-09-21 17:48:11 EDT
+++ This bug was initially created as a clone of Bug #294891 +++
On Mandrake they break the Gettext package up into base, libraries
and then a separate gettext package.
Most users have no need for all the command line tools provided by the gettext
package but simply require the NLS components for their applications. By
breaking gettext up we would reduce the install requirements for most users.
And installing gettext tools only for those who actually need them: translators,
So what do you envisage having in each of those subpackages exactly?
I thanks I am going to move autopoint and gettextize back to the main package.
I'm not familiar with all of Gettext's functionality but this would be my breakdown:
-base - the minimal you would need on a system that provides localised applications
-tools - tools for working with PO files, msgmerge, msgfmt, etc, you could argue
that libgettextpo should go here since if you want this you probably want to
work with PO files in general
-libraries - libgettextpo seems to fit here or in base, there may be others
-devel - building Gettext
I think we could safely get away with the 3: base, tools, devel. In looking I
don't think it makes much sense to divorce the runtime libraries from base.
Also I would put developer required tools eg gettextize and autopoint into
-tools since its not core to the needs of gettext running.
/usr/lib/libgettextlib-0.16.1.so - not 100% sure what each does
/usr/lib/libgettextsrc-0.16.1.so - not 100% sure what each does
envsubst - unsure but seems to belong to base
xgettext - although this could go in base to help programmers.
/usr/lib/gettext/* (I think these are only used by translators)
/usr/bin/recode-sr-latin - unsure what it does
/usr/share/gettext/projects/* - since these are for translators not building
/usr/share/gettext/po/* - unsure what this stuff is for
/usr/lib/libgettextlib.so - currently in -devel (shouldn't this go to base?)
/usr/lib/libgettextsrc.so - currently in -devel (shouldn't this go to base?)
Well that's my idea. Hope it helps.
Thanks for the reply.
So currently in fedora devel (aka rawhide) we have:
gettext, gettext-libs and gettext-devel.
What do you see as the main advantage of splitting gettext to base and tools?
(I haven't tried but naively it looks like base will still be pretty big because
For me the main advantage of splitting out the tools is simply that while most
people need the libraries to manage the localisation. Almost nobody actually
needs to tools to manipulate these files unless they are actually translating.
I'm not sure what the size issues are, but with Fedora being used in various
places it does shave off some bytes that for most people are uneeded. But
that's academic until we see numbers.
Ok, to me it seems naively ok to split out:
into a base subpackage, but i really don't know many (any?) packages/projects
that use just these programs? I think bash supports $"string" for l10n.
Do you have any examples in mind? :)
I did a quick scan on my system of /usr/bin/* to see if anything did ".
gettext.sh" and got nothing. I wonder if anything does use that on a Linux box.
Yes bash allows localisation of $"string" (see --dump-po-strings or -D), that is
what is used in all Fedora init scripts.
I'm not sure if anyone uses those functions you've listed. But since my
thinking is that base should allow localisation they should be there.
But to answer your question about any examples... nope none :)
Okay thanks for the information.
Hmm, well until there is a use-case for gettext-base I feel
pretty comfortable with the current subpackaging.
I think things are a bit better now than around the time
this bug was originally filed.
If you still feel strongly about it perhaps we can revisit
it again for Fedora 10.
Yes bug 294891 did correctly address the issue of libgettextpo that initiated
this bug. Am glad we bounced this about just to check so lets wait for some
future use case.
Ok, thanks - deferring this for now.
Please reopen if or when you see a case for revisiting this.