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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
