Bug#1058933: cubemap: introduced new file in /lib
* Steinar H. Gunderson [231218 17:19]:
> On Mon, Dec 18, 2023 at 04:33:26PM +0100, Chris Hofstaedtler wrote:
> > I don't think there is anything you can "ask" about this.
> >
> > Generally the idea is that in trixie and later, --prefix=/usr really
> > means that. Anything that excluded subdirs from ${prefix} should be
> > a thing of the past. If the upstream build system ignores ${prefix}
> > for a certain location, you'll need to override it :-(
>
> Well, it's pretty straight-up autoconf (no automake). Makefile.in contains
>
> PREFIX=@prefix@
> SYSCONFDIR=@sysconfdir@
> LOCALSTATEDIR=@localstatedir@
> LIBDIR=@libdir@
>
> and installs into $(LIBDIR).
>
> dh_auto_configure runs configure with (among others)
>
> --prefix=/usr --libdir=\${prefix}/lib/x86_64-linux-gnu
>
> But nothing ever defines lowercase ${prefix}. It's possible that it expects
> the upstream Makefile to do
>
> prefix=$(PREFIX)
I think thats what dh expects it to contain for everything to work,
yes. You could check out the "hello" source package, which has a bog
standard autoconf/automake setup and has, in Makefile.in:
...
libdir = @libdir@
...
prefix = @prefix@
...
and thus in Makefile:
...
libdir = ${prefix}/lib/x86_64-linux-gnu
...
prefix = /usr
...
> or something similar? But it's unclear to my why it doesn't just do
>
> --libdir=/usr/lib/x86_64-linux-gnu
Good question, don't know. There is no comment explaining this in
the debhelper source; maybe it was to avoid duplication there.
Maybe the easiest is to add --libdir=/usr/lib/${DEB_HOST_MULTIARCH}
to dh_auto_configure?
Best,
Chris
Bug#1058933: cubemap: introduced new file in /lib
On Mon, Dec 18, 2023 at 04:33:26PM +0100, Chris Hofstaedtler wrote:
> I don't think there is anything you can "ask" about this.
>
> Generally the idea is that in trixie and later, --prefix=/usr really
> means that. Anything that excluded subdirs from ${prefix} should be
> a thing of the past. If the upstream build system ignores ${prefix}
> for a certain location, you'll need to override it :-(
Well, it's pretty straight-up autoconf (no automake). Makefile.in contains
PREFIX=@prefix@
SYSCONFDIR=@sysconfdir@
LOCALSTATEDIR=@localstatedir@
LIBDIR=@libdir@
and installs into $(LIBDIR).
dh_auto_configure runs configure with (among others)
--prefix=/usr --libdir=\${prefix}/lib/x86_64-linux-gnu
But nothing ever defines lowercase ${prefix}. It's possible that it expects
the upstream Makefile to do
prefix=$(PREFIX)
or something similar? But it's unclear to my why it doesn't just do
--libdir=/usr/lib/x86_64-linux-gnu
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#1058933: cubemap: introduced new file in /lib
* Steinar H. Gunderson [231218 16:07]:
> On Mon, Dec 18, 2023 at 03:28:54PM +0100, Chris Hofstaedtler wrote:
> > cubemap 1.5.1-1 introduced a new file into
> > /lib/${DEB_HOST_MULTIARCH}. This is diametral to the ongoing
> > UsrMerge effort [1].
>
> Can you say something about where I should get libdir from?
> Some dpkg invocation?
I don't think there is anything you can "ask" about this.
Generally the idea is that in trixie and later, --prefix=/usr really
means that. Anything that excluded subdirs from ${prefix} should be
a thing of the past. If the upstream build system ignores ${prefix}
for a certain location, you'll need to override it :-(
Best,
Chris
Bug#1058933: cubemap: introduced new file in /lib
On Mon, Dec 18, 2023 at 03:28:54PM +0100, Chris Hofstaedtler wrote:
> cubemap 1.5.1-1 introduced a new file into
> /lib/${DEB_HOST_MULTIARCH}. This is diametral to the ongoing
> UsrMerge effort [1].
Can you say something about where I should get libdir from?
Some dpkg invocation?
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#1058933: cubemap: introduced new file in /lib
Package: cubemap
Version: 1.5.1-1
User: helm...@debian.org
Usertags: dep17m2
Severity: important
Hello!
cubemap 1.5.1-1 introduced a new file into
/lib/${DEB_HOST_MULTIARCH}. This is diametral to the ongoing
UsrMerge effort [1].
This having already happened in unstable is somewhat unfortunate,
because it now presents extra work.
As long as this has not reached testing, the easiest thing to do
would be:
Immediately upload a new version of cubemap, which fulfills all of:
1) install ffmpeg_metacube_hack.so into /usr/lib/${DEB_HOST_MULTIARCH}
2) stop creating /lib/${DEB_HOST_MULTIARCH}
3) does exactly no other changes
and let that migrate, and then we can pretend this never happened.
If for some reason this timing is not possible, I would encourage
you to do all of the following:
Upload a new version of cubemap to *experimental* which:
1) installs ffmpeg_metacube_hack.so into /usr/lib/${DEB_HOST_MULTIARCH}
2) stops creating /lib/${DEB_HOST_MULTIARCH}
and let it stay in experimental for a few days, so dumat[1] and
humans can analyze the change.
In addition, if src:cubemap will introduce any other changes during
the trixie cycle (file moves, package renames, splits, any other
reorganization), please also upload to experimental for the same
benefit as above.
Thanks,
Chris
[1] https://wiki.debian.org/UsrMerge
