+++ 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.
thanks
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. 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.
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.)
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: /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? :)
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.