Hi,
Sorry for the late response.
I am currently on vacation with limited internet access.
On Sun, Aug 13, 2017 at 01:22:20AM +0200, Jan Kratochvil wrote:
On Mon, 31 Jul 2017 13:16:29 +0200, Mark Wielaard wrote:
> - Putting extra files under /usr/lib/debug causes:
> error: Installed (but unpackaged) file(s) found:
>
/usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.opt-1.pyc
>
/usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.opt-2.pyc
>
/usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.pyc
>
/usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.opt-1.pyc
>
/usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.opt-2.pyc
>
/usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.pyc
> /usr/lib/debug/usr/lib64/libpython3.6dm.so.1.0.debug-gdb.py
> /usr/lib/debug/usr/lib64/libpython3.6m.so.1.0.debug-gdb.py
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1476593
>
> This is caused by split debuginfo checking which file corresponds to
> which main/sub-package. Without split debuginfo anything found
> under /usr/lib/debug is just put into the -debuginfo package, no
> questions asked.
>
> The immediate workaround is to add the following to your spec file:
> %undefine _debuginfo_subpackages
>
> This disables split debuginfo packages and just generates one big
> -debuginfo packages with everything under /usr/lib/debug/ included.
>
> But this might or might not be a packaging bug. In particular if it
> contains generated pyc files those probably really shouldn't be there.
Why not? For *.py files their *.pyc should be also packaged.
Yes. But they are scripts instead of plain debug data or source
files. The *.pyc files might not be generated automatically when such
scripts are put in the automatic generated -debuginfo or -debugsource
packages. Having them in the debuginfo and under /usr/lib/debug will
prevent the debuginfo/source packages from being parallel installable
for example.
> The basic issue is that we have been trying to make the
debuginfo
> packages self-contained and non-conflicting between versions.
> So you can easily install debuginfo for different (bi)arches or
> versions. But some packages assume that if they drop anything
> under /usr/lib/debug it will just magically appear in the debuginfo
> package (which has been historically true). But with the split
> debuginfo we have to make a choice which subpackage it belongs
> to. Best rpm fix would probably be to add such files to the "main"
> debuginfo package.
>
> But it would probably be better to move these files to the
> python3-devel package. Maybe we should discuss with the gdb
> maintainers how/where they would like to see these gdb python
> extensions installed. I doubt the -debuginfo package really is
> the place for them anyway.
I cannot speak for python3-devel. But for package "gdb" I get:
error: Installed (but unpackaged) file(s) found:
/usr/lib/debug/usr/bin/__pycache__/gdb-gdb.cpython-36.opt-1.pyc
/usr/lib/debug/usr/bin/__pycache__/gdb-gdb.cpython-36.pyc
/usr/lib/debug/usr/bin/gdb-gdb.py
And gdb-gdb.py is useful only for debugging /usr/bin/gdb itself.
For that one needs gdb-debuginfo.rpm. And gdb-devel.rpm even does not exist.
The quick workaround if you are blocked right now is to just add
%undefine _debuginfo_subpackages to you spec file. That will stop
rpm from trying to account for every file under /usr/lib/debug.
That of course doesn't fix the underlying issue of having non-debug
files under /usr/lib/debug, but gets you building again.
Long term we will have to figure out a policy to package such
auxiliary scripts.
Cheers,
Mark