gettext packaging bug?

gettext packaging bug?

[Corinna Vinschen]

Hi Chuck,

I was just trying to build a package on a new 64 bit Cygwin test
machine, when I encountered a missing libintl.h.  As it turned out,
I had gettext-devel installed, but not gettext.  In the 64 bit version
of gettext, gettext-devel depends on libintl8, but not on gettext, so
that's that.

However, why is libintl.h in gettext, and not in gettext-devel?

A header file belongs in the devel package if there is one, isn't it?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: gettext packaging bug?

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 5931 bytes --]

On 6/12/2013 11:13 AM, Corinna Vinschen wrote:
> I was just trying to build a package on a new 64 bit Cygwin test
> machine, when I encountered a missing libintl.h.  As it turned out,
> I had gettext-devel installed, but not gettext.  In the 64 bit version
> of gettext, gettext-devel depends on libintl8, but not on gettext, so
> that's that.

Ah, that's a bug in Yaakov's packaging of gettext. On 32bit, 
gettext-devel requires: gettext.

> However, why is libintl.h in gettext, and not in gettext-devel?
>
> A header file belongs in the devel package if there is one, isn't it?

The upstream maintainer, Bruno Haible, strongly recommends certain 
conventions when packaging gettext.  While we have to deviate from those 
recommendations somewhat for cygwin, I tried to adhere as closely as I 
could to them. See the attached PACKAGING file; what Bruno calls 
"gettext-tools" I've packaged as "gettext-devel" more or less, and what 
he calls "gettext-runtime" I've packaged as "gettext", with obvious 
exception that DLLs themselves all get their own package(s).

However, in actuality, neither Bruno's "gettext-runtime" (our gettext) 
nor his "gettext-tools" (our gettext-devel) really represent a 
"traditional" runtime-vs-devel split.

Note that this means all of the following:

/usr/lib/libintl.a
/usr/lib/libintl.dll.a
/usr/lib/libintl.la
/usr/include/libintl.h

are actually in 'gettext' and *not* in gettext-devel.

I'm open to reorganizing the gettext packaging (ignore Bruno?) but we 
*really* don't want to make gettext depend on gettext-devel 
(gettext-devel pulls in git, to make autopoint work).  The other way 
around -- where gettext-devel requires: gettext -- could work, and in 
fact *is* the current practice at least in the 32bit package.


Background info:

With the release of 0.11 way back in 2002, gettext itself was 
reorganized into supporting libs (in addition to the pre-existing 
libintl) and application code. At that time, Bruno made the original 
packaging suggestions; I tried to explain my version of them in the 
cygwin README (relevant section pasted below):

0.11.2:
> Between 0.10.40 and 0.11.2, there were massive changes in the
> gettext package.  Much of the code for the development tools
> was pulled out and placed into two additional libraries,
> libgettextlib and libgettextsrc.  These are NOT for use by
> outside programs, but only by the gettext tools themselves --
> so the header files, static lib, and import lib are NOT
> included in the binary package (this ommission is actually
> *recommended* by Bruno in the PACKAGING file).
>   However, in general these two support libraries are built as
> shared libraries (DLLs), so the cyggettextlib-0.11.2.dll and
> cyggettextsrc-0.11.2.dll files are installed.

  [*]

 > Also, these
> libraries are NOT versioned according to the normal libtool
> method (--version-info x:y:z), but instead are versioned
> using the --release 0.11.2 method.  That means that every
> new release of gettext will ship new versions (0.11.3, etc)
> of these two libs -- and since no package other than
> gettext itself uses them, we don't need to worry about
> keeping old versions around for compatibility and stuff.
>   So, I've made all of the necessary changes to enable
> these two libs to be built as DLLs -- which include:
>   1) use the functional, not macro, form of po_gram_error
>      and po_gram_error_at_line.  Otherwise, our client
>      programs msg*.exe will attempt, via the macro, to
>      directly access fields of the imported structure variable
>      gram_pos.
>        changes: src/po-lex.h src/po-lex.c
>   2) provide an accessor function for the imported
>      array-of-structures variable plural_table[] (otherwise
>      our client programs will attempt to directly access
>      elements of the table -- a no-no for auto-import).
>        changes: src/plural-table.h src/plural-table.c
>                 src/msgfmt.c src/msginit.c
>   3) pull out the getopt functions from these libraries,

[ (3) deleted because the getopt manipulations are no longer necessary
nor performed in builds of modern gettext for cygwin]

[*] didn't actually get this working in 0.11, so it had to wait until 
the 0.12 era, when I finally got the gettextsrc and gettextlib libraries 
building as DLLs (along with gettextpo), There was a slight tweak:

0.12.1:
> Update to the latest release.  Also, now that libtool doesn't relink
> forever, use cyggettextlib-0-12-1.dll and cyggettextsrc-0-12-1.dll.
> Now, the odd thing about this is, cyggettext*-0-12-1 are PRIVATE
> libraries.  Their version number will change with every new release,
> but since nobody (outside of this package) is allowed to use them,
> there's no need to worry about backwards compatibility and keeping
> old versions around and -- you would think -- no need to put them
> into their own package.
>
> BUT.  cyggettextpo-0.dll provides the PUBLIC interface to those
> two private libraries.  Thus, external packages might depend on
> cyggettextpo-0.dll (which in turn depends on cyggettextlib-X-Y-Z
> and cyggettextsrc-X-Y-Z, but they don't know that).  Thus,
> cyggettextpo-0.dll needs to be in its own package -- AND
> cyggettextsrc-X-Y-Z.dll / cyggettextlib-X-Y-Z.dll need to be with
> it.  Thus, later versions of gettextpo will look like this:
>
>   libgettextpo0 (first)
>     cyggettextpo-0.dll
>     cyggettextsrc-0-12-1.dll
>     cyggettextlib-0-12-1.dll
>   libgettextpo0 (next, but public interface gettextpo hasn't changed)
>     cyggettextpo-0.dll
>     cyggettextsrc-0-12-2.dll
>     cyggettextlib-0-12-2.dll
>   etc.
>
> External packages keep seeing cyggettextpo-0.dll, but behind the scenes
> the private library versions keep changing.  But they MUST be
> distributed together with the public lib, or the whole thing breaks.
>
> Sigh.

Hope that helps. For now, the quick fix is to add gettext to 
gettext-devel's requires: line on 64bit.

--
Chuck


[-- Attachment #2: PACKAGING --]
[-- Type: text/plain, Size: 6578 bytes --]

Packaging hints for binary package distributors
===============================================

Although the source of the gettext package comes as a single package,
I recommend that in distributions of binary packages the installed files
be split into two packages:

   gettext-runtime
        Contents: Runtime libraries and programs.
        Audience: Anyone who wants to run internationalized programs.

   gettext-tools
        Contents: Tools and documentation for developers and translators.
        Audience: Anyone who wants to develop or localize internationalized
                  programs, i.e. developers and translators.
        Dependencies: requires gettext-runtime.

The 'gettext-runtime' binary package is much smaller than the 'gettext-tools'
binary package (420 KB versus 5.5 MB). I recommend to include it in the default
installation list, like GNU 'coreutils'; in fact, the runtime programs are
utilities for sh programs.

The 'gettext-runtime' binary package can be installed by doing

      cd gettext-runtime
      ./configure
      make
      make install

The 'gettext-tools' binary package can be installed by doing

      cd gettext-tools
      ./configure
      make
      make install

If you want to install both at the same time, you simply do at the toplevel
directory:

      ./configure
      make
      make install

The precise split between gettext and gettext-tools is according to the
following file list.

   gettext-runtime

      $prefix/share/gettext/ABOUT-NLS

      $prefix/bin/gettext
      $prefix/bin/ngettext
      $prefix/bin/envsubst
      $prefix/bin/gettext.sh
      $prefix/share/man/man1/gettext.1
      $prefix/share/man/man1/ngettext.1
      $prefix/share/man/man1/envsubst.1
      $prefix/share/doc/gettext/gettext.1.html
      $prefix/share/doc/gettext/ngettext.1.html
      $prefix/share/doc/gettext/envsubst.1.html
      $prefix/share/locale/*/LC_MESSAGES/gettext-runtime.mo

      $prefix/lib/libintl.*               (not installed on glibc systems)
      $prefix/lib/charset.alias           (not installed on glibc systems)
      $prefix/share/locale/locale.alias   (not installed on glibc systems)
      $prefix/include/libintl.h           (not installed on glibc systems)
      $prefix/share/man/man3/*
      $prefix/share/doc/gettext/*.3.html

      $prefix/share/gettext/libintl.jar
      $prefix/share/doc/gettext/javadoc2/*

      $prefix/lib/GNU.Gettext.dll
      $prefix/share/doc/gettext/csharpdoc/*

      $prefix/lib/libasprintf.*
      $prefix/include/autosprintf.h
      $prefix/share/doc/libasprintf/autosprintf.html
      $prefix/info/autosprintf.info

   gettext-tools

      Everything else, i.e. currently:

      $prefix/bin/msg*
      $prefix/bin/xgettext
      $prefix/bin/gettextize
      $prefix/bin/autopoint
      $prefix/bin/recode*
      $prefix/share/man/man1/msg*.1
      $prefix/share/man/man1/xgettext.1
      $prefix/share/man/man1/gettextize.1
      $prefix/share/man/man1/autopoint.1
      $prefix/share/doc/gettext/msg*.1.html
      $prefix/share/doc/gettext/xgettext.1.html
      $prefix/share/doc/gettext/gettextize.1.html
      $prefix/share/doc/gettext/autopoint.1.html
      $prefix/share/doc/gettext/gettext_*.html
      $prefix/share/doc/gettext/FAQ.html
      $prefix/share/doc/gettext/examples/*
      $prefix/info/gettext.info*
      $prefix/include/gettext-po.h
      $prefix/lib/libgettextlib*
      $prefix/lib/libgettextsrc*
      $prefix/lib/libgettextpo*
      $prefix/lib/preloadable_libintl.so  (only installed on glibc systems)
      $prefix/lib/gettext/*
      $prefix/share/locale/*/LC_MESSAGES/gettext-tools.mo
      $prefix/share/gettext/config.rpath
      $prefix/share/gettext/intl/*
      $prefix/share/gettext/po/*
      $prefix/share/gettext/projects/*
      $prefix/share/gettext/gettext.h
      $prefix/share/gettext/gettext.jar   (only installed if gcj is not present)
      $prefix/share/gettext/msgunfmt.tcl
      $prefix/share/gettext/archive.git.tar.gz
      $prefix/share/gettext/archive.dir.tar.gz   (only installed if --without-git specified)
      $prefix/share/gettext/archive.cvs.tar.gz   (only installed if --with-cvs specified)
      $prefix/share/aclocal/codeset.m4
      $prefix/share/aclocal/fcntl-o.m4
      $prefix/share/aclocal/gettext.m4
      $prefix/share/aclocal/glibc2.m4
      $prefix/share/aclocal/glibc21.m4
      $prefix/share/aclocal/iconv.m4
      $prefix/share/aclocal/intdiv0.m4
      $prefix/share/aclocal/intl.m4
      $prefix/share/aclocal/intldir.m4
      $prefix/share/aclocal/intlmacosx.m4
      $prefix/share/aclocal/intmax.m4
      $prefix/share/aclocal/inttypes_h.m4
      $prefix/share/aclocal/inttypes-pri.m4
      $prefix/share/aclocal/lcmessage.m4
      $prefix/share/aclocal/lib-ld.m4
      $prefix/share/aclocal/lib-link.m4
      $prefix/share/aclocal/lib-prefix.m4
      $prefix/share/aclocal/lock.m4
      $prefix/share/aclocal/longlong.m4
      $prefix/share/aclocal/nls.m4
      $prefix/share/aclocal/po.m4
      $prefix/share/aclocal/printf-posix.m4
      $prefix/share/aclocal/progtest.m4
      $prefix/share/aclocal/size_max.m4
      $prefix/share/aclocal/stdint_h.m4
      $prefix/share/aclocal/uintmax_t.m4
      $prefix/share/aclocal/visibility.m4
      $prefix/share/aclocal/wchar_t.m4
      $prefix/share/aclocal/wint_t.m4
      $prefix/share/aclocal/xsize.m4
      $prefix/share/emacs/site-lisp/po-compat.el
      $prefix/share/emacs/site-lisp/po-compat.elc
      $prefix/share/emacs/site-lisp/po-mode.el
      $prefix/share/emacs/site-lisp/po-mode.elc
      $prefix/share/emacs/site-lisp/start-po.el
      $prefix/share/emacs/site-lisp/start-po.elc


Java support:
-------------

If GNU gcj is available at build time, two programs will be built as native
executables:
      $prefix/lib/gettext/gnu.gettext.*
and the gettext-tools package will therefore have a runtime dependency to
libgcj.so.

If GNU gcj is not available at build time but another Java implementation is
available instead, the two programs will be compiled to Java bytecode only:
      $prefix/share/gettext/gettext.jar
and the gettext-tools package will therefore have a runtime dependency to
the Java virtual machine (Sun Java2, IBM Java2, GNU libgcj.jar, or other).


C# support:
-----------

For C# support, one of pnet or mono must be available at build time; it must
also be available at run time. If you have both available, choose the desired
one through the configure option. Note there is no interoperability currently
between pnet and mono: Programs compiled with pnet don't run with mono, and
vice versa.

Re: gettext packaging bug?

[Corinna Vinschen]

On Jun 12 15:08, Charles Wilson wrote:
> On 6/12/2013 11:13 AM, Corinna Vinschen wrote:
> >I was just trying to build a package on a new 64 bit Cygwin test
> >machine, when I encountered a missing libintl.h.  As it turned out,
> >I had gettext-devel installed, but not gettext.  In the 64 bit version
> >of gettext, gettext-devel depends on libintl8, but not on gettext, so
> >that's that.
> 
> Ah, that's a bug in Yaakov's packaging of gettext. On 32bit,
> gettext-devel requires: gettext.
> 
> >However, why is libintl.h in gettext, and not in gettext-devel?
> >
> >A header file belongs in the devel package if there is one, isn't it?
> 
> The upstream maintainer, Bruno Haible, strongly recommends certain
> conventions when packaging gettext.  While we have to deviate from
> those recommendations somewhat for cygwin, I tried to adhere as
> closely as I could to them. See the attached PACKAGING file; what
> Bruno calls "gettext-tools" I've packaged as "gettext-devel" more or
> less, and what he calls "gettext-runtime" I've packaged as
> "gettext", with obvious exception that DLLs themselves all get their
> own package(s).
> 
> However, in actuality, neither Bruno's "gettext-runtime" (our
> gettext) nor his "gettext-tools" (our gettext-devel) really
> represent a "traditional" runtime-vs-devel split.
> 
> Note that this means all of the following:
> 
> /usr/lib/libintl.a
> /usr/lib/libintl.dll.a
> /usr/lib/libintl.la
> /usr/include/libintl.h
> 
> are actually in 'gettext' and *not* in gettext-devel.
> 
> I'm open to reorganizing the gettext packaging (ignore Bruno?) but
> we *really* don't want to make gettext depend on gettext-devel
> (gettext-devel pulls in git, to make autopoint work).  The other way
> around -- where gettext-devel requires: gettext -- could work, and
> in fact *is* the current practice at least in the 32bit package.

The dependcy isn't picked up automatically, that's why it's missing
in the 64 bit package, perhaps.

Either way, I would always expect the files required to build
against gettext in the gettext-devel package, but I guess if the
dependency is fixed, it should be ok.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: gettext packaging bug?

[Corinna Vinschen]

On Jun 12 21:42, Corinna Vinschen wrote:
> On Jun 12 15:08, Charles Wilson wrote:
> > On 6/12/2013 11:13 AM, Corinna Vinschen wrote:
> > >I was just trying to build a package on a new 64 bit Cygwin test
> > >machine, when I encountered a missing libintl.h.  As it turned out,
> > >I had gettext-devel installed, but not gettext.  In the 64 bit version
> > >of gettext, gettext-devel depends on libintl8, but not on gettext, so
> > >that's that.
> > 
> > Ah, that's a bug in Yaakov's packaging of gettext. On 32bit,
> > gettext-devel requires: gettext.
> > [...]
> > I'm open to reorganizing the gettext packaging (ignore Bruno?) but
> > we *really* don't want to make gettext depend on gettext-devel
> > (gettext-devel pulls in git, to make autopoint work).  The other way
> > around -- where gettext-devel requires: gettext -- could work, and
> > in fact *is* the current practice at least in the 32bit package.
> 
> The dependcy isn't picked up automatically, that's why it's missing
> in the 64 bit package, perhaps.
> 
> Either way, I would always expect the files required to build
> against gettext in the gettext-devel package, but I guess if the
> dependency is fixed, it should be ok.

FYI, I fixed the dependency in the 64 bit distro manually for now.

Btw., any chance you could have a look into a 64 bit inetutils? :}


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: gettext packaging bug?

[Yaakov (Cygwin/X)]

On 2013-06-12 14:08, Charles Wilson wrote:
> On 6/12/2013 11:13 AM, Corinna Vinschen wrote:
>> However, why is libintl.h in gettext, and not in gettext-devel?
>>
>> A header file belongs in the devel package if there is one, isn't it?
>
> The upstream maintainer, Bruno Haible, strongly recommends certain
> conventions when packaging gettext.  While we have to deviate from those
> recommendations somewhat for cygwin, I tried to adhere as closely as I
> could to them. See the attached PACKAGING file; what Bruno calls
> "gettext-tools" I've packaged as "gettext-devel" more or less, and what
> he calls "gettext-runtime" I've packaged as "gettext", with obvious
> exception that DLLs themselves all get their own package(s).
>
> However, in actuality, neither Bruno's "gettext-runtime" (our gettext)
> nor his "gettext-tools" (our gettext-devel) really represent a
> "traditional" runtime-vs-devel split.
>
> Note that this means all of the following:
>
> /usr/lib/libintl.a
> /usr/lib/libintl.dll.a
> /usr/lib/libintl.la
> /usr/include/libintl.h
>
> are actually in 'gettext' and *not* in gettext-devel.

IMO they really should be in the latter; if you're building a package 
which uses l10n, you need it anyway for autopoint, msgfmt, etc.


Yaakov

Re: gettext packaging bug?

[Charles Wilson]

On 6/12/2013 10:50 PM, Yaakov (Cygwin/X) wrote:
> On 2013-06-12 14:08, Charles Wilson wrote:
>> However, in actuality, neither Bruno's "gettext-runtime" (our gettext)
>> nor his "gettext-tools" (our gettext-devel) really represent a
>> "traditional" runtime-vs-devel split.
>>
>> Note that this means all of the following:
>>
>> /usr/lib/libintl.a
>> /usr/lib/libintl.dll.a
>> /usr/lib/libintl.la
>> /usr/include/libintl.h
>>
>> are actually in 'gettext' and *not* in gettext-devel.
>
> IMO they really should be in the latter; if you're building a package
> which uses l10n, you need it anyway for autopoint, msgfmt, etc.

Right, which is why gettext-devel *should* (and on 32bit, does) depend 
on gettext.

However, I'll investigate how the linux distros package gettext & co. 
It's possible TRTD is to have libintl-devel, libasprintf-devel, 
libgettextpo-devel, etc...and (most of) gettext-devel is transferred to 
gettext-tools.  As I said, I'll investigate.

--
Chuck

64bit inetutils request [Was:: gettext packaging bug?]

[Charles Wilson]

On 6/12/2013 3:47 PM, Corinna Vinschen wrote:
> Btw., any chance you could have a look into a 64 bit inetutils? :}

Oh, ouch. That's going to be miserable, assuming I do full testing of 
the included servers and clients. For this reason, it was on the very 
END of my TODO list.

Or...I could just compile it and wait for the bug reports to roll in. :-)

--
Chuck

Re: 64bit inetutils request [Was:: gettext packaging bug?]

[Corinna Vinschen]

On Jun 16 17:54, Charles Wilson wrote:
> On 6/12/2013 3:47 PM, Corinna Vinschen wrote:
> >Btw., any chance you could have a look into a 64 bit inetutils? :}
> 
> Oh, ouch. That's going to be miserable, assuming I do full testing
> of the included servers and clients. For this reason, it was on the
> very END of my TODO list.
> 
> Or...I could just compile it and wait for the bug reports to roll in. :-)

Heh.  I was just nudging to get this in the distro.  If you're feeling
uncomfortable to provide it yet, it's ok.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat