pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/42960 (expat/ picks up from X11BASE for non-X11 program)

The following reply was made to PR pkg/42960; it has been noted by GNATS.

From: Matthias Drochner <>
To: <>
Cc: <>, <>, 
        <>, <>, 
Subject: Re: pkg/42960 (expat/ picks up from X11BASE 
 for non-X11 program)
Date: Fri, 12 Mar 2010 20:12:23 +0100 said:
 > Can you have a look at this Matthias ? Thanks
 I can give some comments at least. Unfortunately I don't have an easy
 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
 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
 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:
    -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
 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

Home | Main Index | Thread Index | Old Index