Bug 300161 - split gettext into base, libraries, gettext, devel
split gettext into base, libraries, gettext, devel
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: gettext (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-21 08:11 EDT by Dwayne Bailey
Modified: 2009-09-21 17:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-27 20:30:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dwayne Bailey 2007-09-21 08:11:21 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,
programmers, etc.
Comment 1 Jens Petersen 2007-09-21 08:18:05 EDT
thanks
Comment 2 Jens Petersen 2008-01-23 20:54:45 EST
So what do you envisage having in each of those subpackages exactly?
Comment 3 Jens Petersen 2008-01-23 22:17:34 EST
I thanks I am going to move autopoint and gettextize back to the main package.
Comment 4 Dwayne Bailey 2008-01-24 04:01:12 EST
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.

BASE
gettext
ngettext
/usr/share/locale/*/LC_MESSAGES/gettext-runtime.mo
/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
/usr/bin/gettext.sh
/usr/share/doc/gettext-0.16.1
/usr/share/info/gettext.info.gz
envsubst - unsure but seems to belong to base

TOOLS
msgattrib
msgcat
msgcmp
msgcomm
msgconv
msgen
msgexec
msgfilter
msgfmt
msggrep
msginit
msgmerge
msgunfmt
msguniq
xgettext - although this could go in base to help programmers.
/usr/share/locale/*/LC_MESSAGES/gettext-tools.mo
/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

DEVEL
/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?)
The rest

Well that's my idea.  Hope it helps.
Comment 5 Jens Petersen 2008-02-14 02:21:39 EST
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
of libgettextlib.)
Comment 6 Dwayne Bailey 2008-02-14 09:17:45 EST
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.
Comment 7 Jens Petersen 2008-02-15 03:48:14 EST
Ok, to me it seems naively ok to split out:

/bin/gettext
%{_bindir}/envsubst
%{_bindir}/gettext
%{_bindir}/gettext.sh
%{_bindir}/ngettext
%{_mandir}/man1/envsubst.1*
%{_mandir}/man1/gettext.1*
%{_mandir}/man1/ngettext.1*

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? :)
Comment 8 Dwayne Bailey 2008-02-18 16:38:39 EST
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 :)
Comment 9 Jens Petersen 2008-02-27 02:22:29 EST
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.
Comment 10 Dwayne Bailey 2008-02-27 09:07:29 EST
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.
Comment 11 Jens Petersen 2008-02-27 20:30:10 EST
Ok, thanks - deferring this for now.
Please reopen if or when you see a case for revisiting this.

Note You need to log in before you can comment on or make changes to this bug.