GTG [0.6] itself installs into /usr/lib/python3/dist-packages/ instead of /usr/share/gtg on Debian

[khurshid-alam]

Debian Salsa building with dh $@ --with python3 --buildsystem=meson

I think it's due to meson build. GTG itself is not a python library and shouldn't be installed in the same location as liblarch.

The install file correctly put authors into usr/share/doc/gtg/ and xpm into /usr/share/pixmaps but not core files.

I am posting here since salsa repo doesn't have any issue tracker.

[nekohayo]

Hmm, could you provide some links to authoritative documentation that this is indeed "wrong", and not just for Debian but also distros in general? and the best practices with Meson in this case.

Note that we use flatpak as the primary/official upstream packaging mechanism, so I'd like to be sure this is an upstream problem rather than "it's the distro's choice", too. I know nothing about packaging, so someone would need to provide a patch for this, ideally with some confirmation/input from distro packagers and linuxland pythonistas to confirm that the patch has the right approach and won't break things.

[eli-schwartz]

GTG itself is not a python library and shouldn't be installed in the same location as liblarch.

Many python programs are not python libraries. That doesn't mean they are forbidden to be installed to python's global import path. It just means that if they do so, other software isn't allowed to import the GTG internal code, and if they do then they should expect to break.

What is the advantage of moving GTG/ out of the global import path?

• you make it physically impossible for people to do import GTG no matter how ill advised

What is the disadvantage?

• you have to juggle the sys.path as part of the startup script
• application packagers (such as linux distros) may not have hooks set up to compile bytecode in unusual places

[khurshid-alam]

you make it physically impossible for people to do import GTG no matter how ill advised

Yes, it is basically because of that reason. Citing security reasons.

Hmm, could you provide some links to authoritative documentation that this is indeed "wrong", and not just for Debian but also distros in general?

There is no such absolute prefered method documented. But when you ask on debian mailing list, they advised against it because of above reason, at least on deb based distros.

But I am ok with since it doesn't stop gtg from working. So it can be closed.

[eli-schwartz]

I would appreciate additional details about how installing GTG in a place where people can inadvisably do import GTG is a "security" problem.

What hacking vulnerability is introduced by this? I'd love to know. Maybe you can provide a link to the Debian mailing list where someone claimed this is the case?