Re: pkg/42960 (expat/buildlink3.mk picks up libexpat.so from X11BASE for non-X11 program)

[Matthias Drochner <M.Drochner%fz-juelich.de@localhost>]

gls%NetBSD.org@localhost said:
> Can you have a look at this Matthias ? Thanks

I can give some comments at least. Unfortunately I don't have an easy
solution.

The problem is that we need an "expat" for some parts of native X11 -
basically libXft and xterm, through fontconfig and freetype2.
(The latter two are also candidates for the same kind of problems
as expat has, because they are used by non-X11 programs as well.)
We can't easily use a pkgsrc expat (or freetype or fontconfig)
on a native-X11 system because it can lead to the situation that
a program ends up pulling in both versions through shared libs
or dynamically loaded objects, causing all kinds of mysterious
failures and crashes. We had lots of these problems with native
xfree86 before modular-x11 was available. People tried at least to
make sure that native and pkgsrc libs had different major numbers,
but this doesn't fix the problem, it only makes it easier to
detect.

I see 4 ways to approach the problem:
1. Provide binary pkgs built with modular X11. This would be clean
   and sane, but it was told that the bulk build servers don't
   have the capacity to do this atm.
   (There should also be some naming scheme or so to make sure
   that native-x11 and modular-x11 pkgs don't get mixed.)
2. Hide the native-x11 versions of the offending libraries namespace-
   wise (rename exported symbols, change SONAME) to make sure they
   are only used within the native-X11 code and never referenced
   by pkgsrc. libXft's API uses some fontconfig definitions, so
   one would need to be careful that every future pkgsrc version
   of fontconfig is ABI compatible... It's not easy, but worth
   considering.
3. Put expat et al. into base (as proposed in PR pkg/42960), or
   some in-between entity. That's technically easy, but poor engineering
   for some reasons:
   -bloat
   -It doesn't really fix the problem. base doesn't get updated much
    after a release, and if it does, it is restricted to binary-compatible
    versions. pkgsrc evolves fast, and after a while users want/need
    a newer version which is in pkgsrc, and we'll get the problem
    of duplicated libraries again.
4. Use pkgsrc expat (et al.) for pkgs which don't use other X11 libraries,
   as proposed in this PR. There is still the danger that the native
   and pkgsrc libs get mixed in some pkg down the dependency chain.
   It might be manageable, needs detailed checks, but that close to
   a pkgsrc freeze it can't be done anyway.

Imho the best way would be (1). Just look at the pkgsrc bulk build logs
for NetBSD-4 with native-x11. Thousands of failures because the x11
implementation doesn't match today's expectations. For me this means
that pkgsrc with native-x11 doesn't work in the long run.
For now, I can only state that users which don't have native-x11
installed can't use the official binary pkgs but need to compile
their own.

best regards
Matthias





------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------