Hi Jan,

On Do 16 Feb 2012 00:28:40 CET Jan Engelhardt wrote:

On Wednesday 2012-02-15 23:56, Mike Gabriel wrote:
Xcomp, Xcompext and Xcompshad are specific to NX and did not clash with
any Xorg-X11 lib, so I chose not to add a prefix at first. But I do not
really mind them getting a NX_ prefix either. The pkgconfig files also
need updating, they still show the old names.

There some more, how about those?

mike@minobo:~/MyDocuments/4projects/nwt-git/build/cowdancer$ dpkg -L libnx-x11
| grep -v NX_

ximcp et al is not installed by `make install`, hence it was left untouched.
That is also my beef with all the non-NX-inherited packages (x2goclient,
x2goserver), that there is no, or an incomplete `make install` and
therefore have to tediously call install(1) manually in rpmspec's

We love to receive patches that fix the Makefiles. We ourselves do not need the install/uninstall stuff in the Makefiles as we use the debhelper packaging for Debian. Getting Makefiles straight in upstream is our courtesy to people packaging for other distros. Any patch that improves this, will get accepted, unless it breaks something completely.

122 ./nx-libs/standard-dirs.diff

libXcomp* are unusable outside of the /usr/${libdir}/nx context. So it is
misleading to place them into /usr/${libdir}. Thus -> patch denied.

The three libs are placed into /usr/lib/nx while all the other
NX-specific libs are in /usr/X11R6/lib/nx.. an inexplicible
discrepancy. Suffice to say /usr/X11R6 is obsolete now and the libs
that previously lived there are now in /usr.

Oh... we (Debian packaging) install into /usr/lib/nx/X11... So this should be
fixed in the Imake files?

As per the Makefile (for example, compshad's Makefile):

        $(INSTALL_LINK) libXcompshad.so.3       $(DESTDIR)$(prefix)/lib/nx

Therefore, the libs will be placed - by default - into /usr/lib/nx
(assuming prefix=/usr). How you manage to get it into /usr/lib/nx/X11

libXcomp* -> /usr/lib/nx/
nx-X11 & co -> /usr/lib/nx/X11

I will declare as a riddle, but I guess the culprit are Debian's
debian/*.install files which seem to completely throw `make install`
results overboard.

Yes, the magic is in /debian/*.install.

102 ./nx-libs/so-version.diff

Partially accepted:

The question here is whether someone populated the SO version with
the package version because they had nothing better to do, or
because they are vowing to newer remove/change any existing interface
until .so.4. There was no way to tell, hence using this patch.--
which, as I review it, notice that it is incomplete.

Incomplete in what way?

If one chooses to use libXcompshad-3.5.0.so, the SONAME should
reflect that and (as a result) there should be no libXcompshad.so.3
link either (because the SONAME is not libXcompshad.so.3 any longer).

In Debian the libs look like this:

libXcompshad.so (symlink)
libXcompshad.so.3 (symlink)

Using libXcompshad-3.5.0.so is only second choice, as described here:

Actually I threw this patch out again and replaced it by

# Need to do this since %%nxprefix (resp. %%_libexecdir) is variadic.
perl -i -pe 's{^(#define ProjectRoot)\s.*}{$1 %nxprefix}' \

because libexecdir is not necessarily /usr/lib, but e.g. /usr/libexec.

I will build a preview tarball of nx-libs soon. Could you simply patch against
that one?

It's a command inside the nx-libs.spec file I have. It is nothing
that could be patched in nx-libs/, because nx-libs does not provide
for something like

./configure --libexecdir=/usr/myfunnyplace/NX3

to be run.

Ah... ok... I guess I leave the patch in for now, anyway.



mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de


Attachment: pgpR5Cno9ECDS.pgp
Description: Digitale PGP-Unterschrift

X2Go-Dev mailing list

Reply via email to