Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 560856 - dev-libs/kpathsea 6.2.1 moved c-auto.h to libdir
Summary: dev-libs/kpathsea 6.2.1 moved c-auto.h to libdir
Status: VERIFIED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-19 16:20 UTC by David Haller
Modified: 2017-03-19 04:16 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
proposed patch, builds here (dev-libs-kpathsea_c-auto.patch,2.30 KB, patch)
2015-09-19 16:22 UTC, David Haller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Haller 2015-09-19 16:20:35 UTC
see also https://bugs.gentoo.org/show_bug.cgi?id=556074
(I don't think it's a dupe, but its the fix for it)

With 6.2.1, kpathsea moved the 'kpathsea/c-auto.h' header to libdir, e.g. /usr/lib64/kpathsea/c-auto.h.

==== texlive-20150521-source/texk/kpathsea/ChangeLog ====
2015-03-14  Peter Breitenlohner  <peb@mppmu.mpg.de>

        * Makefile.am, kpathsea.pc.in: Install <kpathsea/c-auto.h> under
        ${libdir}.
==== texk/kpathsea/NEWS ====
6.2.1 (for TeX Live 2015, 21 May 2015)
[..]
* install <kpathsea/c-auto.h> in an architecture dependent location
  and use pkg-config to get the required flags.
====
# pkg-config --cflags kpathsea
# equery files dev-libs/kpathsea | grep c-auto
/usr/lib64/kpathsea/c-auto.h
====

This is dainbread. And 6.2.1 is the first release to mention pkg-config in
NEWS, no mention in Changelog! And that header is the only file under
/usr/lib64/kpathsea/. Other apps (e.g. IIRC libjpeg, and many more), store
arch-specific headers in /usr/include for ages. Oh, and of course, the
kernel/glibc.

Reproducible: Always

Steps to Reproduce:
install dev-libs/kpathsea-6.2.1, compile anything using it, e.g. app-text/xdvik.
Actual Results:  
anything using the lib and not using pkgconfig for kpathsea-cflags will barf with a "kpathsea/c-auto.h" not found included from /usr/include/kpathsea/config.h.
Comment 1 David Haller 2015-09-19 16:22:15 UTC
Created attachment 412278 [details, diff]
proposed patch, builds here
Comment 2 Alexis Ballier gentoo-dev 2015-09-19 19:30:15 UTC
Yes, that's the point: arch specific headers should go to libdir; when they don't, it's a mess with multilib. See you examples: glibc & kernel headers :)

I actually agree with upstream here, and packages should use pkg-config for kpathsea.
Comment 3 David Haller 2015-09-20 01:22:28 UTC
Ah, so, *you* are the one that's going to patch and maintain those patches for all packages via ebuilds that do not use pkgconfig yet until upstream fixes it? Hm. 'equery depends' finds "only" 9 dependencies. So have fun patching those ;)
But you're right about headers in $libdir. gcc has them there. But, with e.g. /usr/include/{bits,linux}, I've not run into problems either.

.oO( apart from the fact that I'd want them to point to the headers of the running kernel). I couldn't compile IIRC kcm_joystick once, because the headers (from glibc) were way out of date. Linking those dirs to the includes of the running kernel fixed the problem ;) )Oo.

Not sure what FHS says about config/machine-specific generated headers. It's just I think it's weird to have headers in libdir. I'd prefer $includedir/$arch-$platform$etc/foo/foo.h or something like that. The _file_ is portable. Only the _config_ generated and then stored inside might not. Compare /etc/*. Files are portable, (generated) config is not. Header-files like this are actually config-files and might even belong into {,/usr}/etc/foo or something that's making clear it's generated (not-to-be-changed) config, that would be nice. Using
  ${includedir}/${arch}-${platform}${etc}/${pkg}/foo.h
looks right to me ;) Better than
  ${includedir}/${pkg}/${arch}-${platform}${etc}/foo.h
or
  ${libdir}/${pkg}/[${arch}-${platform}${etc}/{,include/}]foo.h
as it is being used now.

Oh well. Way OT :) But anyway, I suggest to apply my patch to help transition.
Pestering upstream to use pkgconfig is up to the ebuild maintainers.
Comment 4 David Haller 2015-09-20 01:31:16 UTC
I forgot: did you read https://bugs.gentoo.org/show_bug.cgi?id=556074

That is dev-tex/luatex failing to build, due to that. And it has not an explicit dependency on dev-libs/kpathsea! And ISTR, that luatex is default somewhere or other as the tex backend. Yes, upstream will probably fix that soonish and use pkgconfig, but until then?
Comment 5 Mira Ressel 2015-10-01 16:12:09 UTC
I really don't get why this was closed. I agree it's an upstream issue; but still, it causes breakage everywhere. If you're aware of the problem, why can't you include a temporary workaround in the kpathsea ebuild? Do you really consider it an improvement if every user has to debug and solve this on his/her own?
Comment 6 Alexis Ballier gentoo-dev 2015-10-01 17:03:41 UTC
(In reply to Luis Ressel from comment #5)
> I really don't get why this was closed. I agree it's an upstream issue; but
> still, it causes breakage everywhere. If you're aware of the problem, why
> can't you include a temporary workaround in the kpathsea ebuild? Do you
> really consider it an improvement if every user has to debug and solve this
> on his/her own?

File bugs against failing packages. AFAIK, those have all already been fixed. Even before kpathsea was bumped if you look at commit logs.

Except standalone & outdated luatex & dvipdfm ebuilds that cannot be used with the texlive version the "offending" kpathsea version is for and thus for which there's no point in fixing...