Yesterday, there was a bug report on pl (SWI Prolog), a package that I
co-maintain (https://bugzilla.redhat.com/show_bug.cgi?id=471071), and
I'm not sure what to do about it.

I guess SWI assumes that it will be installed with all of its
libraries and related files into a single directory structure, not
following the normal LSB file layout. In the pl-devel package at the
moment, the libraries etc. are under %{_libdir}/pl-%{version}, and
this directory also ends up as the "PLBASE", but the include files are
in their LSB-approved place under /usr/include/pl.

What is the best way to respond to this? I assume it's not encouraged
to put *.h files into %{_libdir}, but on the other hand, breaking
upstream assumptions like this isn't great either. PLBASE is
documented as "the home directory of SWI-Prolog", but I'm not sure if
it's actually guaranteed anywhere that .h files will be in this
directory.

Suggestions welcome!

MEF

--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Mary Ellen Foster wrote, at 11/12/2008 09:36 PM +9:00:

Yesterday, there was a bug report on pl (SWI Prolog), a package that I
co-maintain (https://bugzilla.redhat.com/show_bug.cgi?id=471071), and
I'm not sure what to do about it.

I guess SWI assumes that it will be installed with all of its
libraries and related files into a single directory structure, not
following the normal LSB file layout. In the pl-devel package at the
moment, the libraries etc. are under %{_libdir}/pl-%{version}, and
this directory also ends up as the "PLBASE", but the include files are
in their LSB-approved place under /usr/include/pl.


Cannot this be handled by creating symlink?

Regards,
Mamoru

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Wed, 2008-11-12 at 13:36 +0100, Mary Ellen Foster wrote:
> Yesterday, there was a bug report on pl (SWI Prolog), a package that I
> co-maintain (https://bugzilla.redhat.com/show_bug.cgi?id=471071), and
> I'm not sure what to do about it.
>
> I guess SWI assumes that it will be installed with all of its
> libraries and related files into a single directory structure, not
> following the normal LSB file layout. In the pl-devel package at the
> moment, the libraries etc. are under %{_libdir}/pl-%{version}, and
> this directory also ends up as the "PLBASE", but the include files are
> in their LSB-approved place under /usr/include/pl.
>
> What is the best way to respond to this? I assume it's not encouraged
> to put *.h files into %{_libdir},
Right, but there also is no strict ban on doing so.

More precisely, there are situations when it's advisable to put headers
into some directory below %{_libdir}.

For example, multilib architecture dependent header files are such a
case (c.f. glibc2-devel).

> but on the other hand, breaking
> upstream assumptions like this isn't great either. PLBASE is
> documented as "the home directory of SWI-Prolog", but I'm not sure if
> it's actually guaranteed anywhere that .h files will be in this
> directory.
I would doubt this.

In general, any user expectation on where a set of headers is installed
will inevitably be wrong somewhere and will require adaptation of
applications build-files/makefile.

> Suggestions welcome!
The decision is more or less up to you.

I would not move them to %{_libdir}.

Ralf






--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Wed, Nov 12, 2008 at 01:36:52PM +0100, Mary Ellen Foster wrote:
> What is the best way to respond to this? I assume it's not encouraged
> to put *.h files into %{_libdir}, but on the other hand, breaking
> upstream assumptions like this isn't great either. PLBASE is
> documented as "the home directory of SWI-Prolog", but I'm not sure if
> it's actually guaranteed anywhere that .h files will be in this
> directory.

It's funny this should come up because I noticed that some glib & gtk
packages do this (when packaging for MinGW). eg:

$ find /usr/i686-pc-mingw32/sys-root/mingw/lib/ -name '*.h'
/usr/i686-pc-mingw32/sys-root/mingw/lib/sigc++-2.0/include/sigc++config.h
/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h
/usr/i686-pc-mingw32/sys-root/mingw/lib/gdkmm-2.4/include/gdkmmconfig.h
/usr/i686-pc-mingw32/sys-root/mingw/lib/glibmm-2.4/include/glibmmconfig.h
/usr/i686-pc-mingw32/sys-root/mingw/lib/gtkmm-2.4/include/gtkmmconfig.h
/usr/i686-pc-mingw32/sys-root/mingw/lib/gtk-2.0/include/gdkconfig.h
/usr/i686-pc-mingw32/sys-root/mingw/lib/giomm-2.4/include/giommconfig.h

I left it as the upstream package was for now, but I'm sure this will
come up during review. No idea what the right thing to do is or why
those packages put header files in such a weird place ...

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Thu, 2008-11-13 at 11:38 +0000, Richard W.M. Jones wrote:
> On Wed, Nov 12, 2008 at 01:36:52PM +0100, Mary Ellen Foster wrote:
> > What is the best way to respond to this? I assume it's not encouraged
> > to put *.h files into %{_libdir}, but on the other hand, breaking
> > upstream assumptions like this isn't great either. PLBASE is
> > documented as "the home directory of SWI-Prolog", but I'm not sure if
> > it's actually guaranteed anywhere that .h files will be in this
> > directory.
>
> It's funny this should come up because I noticed that some glib & gtk
> packages do this (when packaging for MinGW). eg:
>
> $ find /usr/i686-pc-mingw32/sys-root/mingw/lib/ -name '*.h'
> /usr/i686-pc-mingw32/sys-root/mingw/lib/sigc++-2.0/include/sigc++config.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/gdkmm-2.4/include/gdkmmconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/glibmm-2.4/include/glibmmconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/gtkmm-2.4/include/gtkmmconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/gtk-2.0/include/gdkconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/giomm-2.4/include/giommconfig.h
>
> I left it as the upstream package was for now, but I'm sure this will
> come up during review. No idea what the right thing to do
The place you list above. These headers are architecture dependent.

i.e. they need to be placed under a multilib'ed directory to be
installable on multilib'ed system.

> is or why
> those packages put header files in such a weird place ...

cf. above.

Ralf


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Thu, Nov 13, 2008 at 11:38:36AM +0000, Richard W.M. Jones wrote:
> On Wed, Nov 12, 2008 at 01:36:52PM +0100, Mary Ellen Foster wrote:
> > What is the best way to respond to this? I assume it's not encouraged
> > to put *.h files into %{_libdir}, but on the other hand, breaking
> > upstream assumptions like this isn't great either. PLBASE is
> > documented as "the home directory of SWI-Prolog", but I'm not sure if
> > it's actually guaranteed anywhere that .h files will be in this
> > directory.
>
> It's funny this should come up because I noticed that some glib & gtk
> packages do this (when packaging for MinGW). eg:
>
> $ find /usr/i686-pc-mingw32/sys-root/mingw/lib/ -name '*.h'
> /usr/i686-pc-mingw32/sys-root/mingw/lib/sigc++-2.0/include/sigc++config.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/gdkmm-2.4/include/gdkmmconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/glibmm-2.4/include/glibmmconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/gtkmm-2.4/include/gtkmmconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/gtk-2.0/include/gdkconfig.h
> /usr/i686-pc-mingw32/sys-root/mingw/lib/giomm-2.4/include/giommconfig.h
>
> I left it as the upstream package was for now, but I'm sure this will
> come up during review. No idea what the right thing to do is or why
> those packages put header files in such a weird place ...

That's not a problem - that's standard practice even on the native
builds of those packages. The config.h files here contain various
macros / defines that are variable according to the build host. By
putting them in the lib directory, you can have -devel packages for
both 32-bit and 64-bit versions installed in parallel & get the correct
definitions. Now this isn't important to MinGW since we only target
Win32, but there's no need to move them.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging