Bug#836453: xserver-xorg-dev: please move xorg-server.pc to a multiarch path
On 10/02/2017 09:48 PM, Helmut Grohne wrote:
> On Sun, Oct 01, 2017 at 10:47:54PM +0200, Julien Cristau wrote:
>>> How do you feel about applying this patch to help with cross-compilation
>>> and (re)bootstrapping?
>>>
>> Unconvinced. d/rules is already too messy as it is.
>
> Indeed. The original patch makes d/rules worse. So I am attaching a new
> patch to improve the situation:
>
> 1. Drop --libdir (to pick up the debhelper default).
>
OK.
> 2. Add --with-module-dir to avoid moving /usr/lib/xorg. Other packages
> place their modules here, so we cannot move it without coordination.
> Given that there can be only one /usr/bin/Xorg and that these
> modules are loaded into that Xorg, I think it should default to
> ${libexecdir}/modules. I can try changing that upstream.
>
Sounds reasonable. Bit of an uphill battle to get all drivers updated,
so not sure this is actually worth it. Possibly we should add comments
to document our overridden paths in configure flags, and leave it at
that, at least for now.
> 3. Add --with-serverconfig-path to avoid moving protocol.txt. It ends
> up in xserver-common, which is Arch:all and thus cannot be
> multiarchy. Again using ${libexecdir} would make more sense.
>
Fair.
> 4. Move the installation of pkgconfig into d/rules as .install files
> cannot contain variables. (Alternatively: use dh-exec)
>
I'd rather not switch to dh-exec if at all possible, so ok.
> 5. d/rules fails to define the architecture variables (e.g.
> DEB_HOST_ARCH_OS). Unless building with dpkg-buildpackage they are
> undefined. So I sneak "include /usr/share/dpkg/architecture.mk" into
> the patch.
>
Looks like a bug in
https://anonscm.debian.org/git/pkg-xorg/xserver/xorg-server.git/commit/?id=29d0f5ae367f0efa80d48990843f2e30019cd233
which we should fix. I think I'd prefer bringing back the explicit
variable definitions to architecture.mk, but don't feel very strongly
either way.
> Ignoring the last point (which is a bug imo), this is a net increase in
> 1 line. Potentially, points 2 and 3 could be upstreamed to further
> reduce messiness.
>
> I hope this works better for you.
>
Thanks,
Julien
Reply to: