[PATCHES] Generate shorter name for extra python files

Andrew Bartlett abartlet at samba.org
Sun Aug 27 07:02:36 UTC 2017

On Tue, 2017-08-22 at 11:25 +0200, Petr Viktorin via samba-technical
> I'm sorry for missing this thread; my vacation-mode filtering is too eager.
> As for the original design, "extra python" allows building two versions 
> of Python by a single `make` invocation. Building for both 2 and 3 at 
> once was a requirement to get the Python3 patches in.
> To make this work, I've reused the mechanism Python uses to allow binary 
> files for multiple versions to co-exist. The "ABI tag" contains just the 
> information needed to distinguish between ABI-incompatible versions.
> Note that "/usr/lib64/pkgconfig/pyldb-util36.pc" does not include all 
> relevant information: the "m" in "cpython-36m-x86_64-linux-gnu" encodes 
> build-time configuration; "dm" would mean a debug build with 
> incompatible ABI.
> See [PEP 3149] if you want details.
> Using the ABI tag as-is essentially puts the burden of distinguishing 
> ABI incompatibilities on Python developers/distributors. It's also quite 
> easy to ask Python for it [0], so, hopefully, buildsystems of packages 
> that depend on the utils can be made to support this.
> That said, I'm not familiar with pkg-config or multilib packaging 
> outside of Python, or across distros. This is the Python way to do it; 
> please adjust if it makes sense.
> Another note on the original design intent: generally, the "extra 
> python" needs to be version 3, and the "normal" Python could be either 2 
> *or* a different version of 3. It's never been tested with py3 as the 
> non-extra Python, and I'm sure it doesn't actually work now, but at some 
> point it'll be necessary to make the "non-extra" Python be Python 3, 
> preferably with the relevant name mangling. Please don't assume that 
> "not extra-python" implies Python 2.
> [PEP 3149]: https://www.python.org/dev/peps/pep-3149/
> [0] import sysconfig; sysconfig.get_config_var('SOABI')

Thanks for the details.  If you could work with Lumir and Andreas to
propose something that follows the above and meets Lumir's requirements
that would be great.  We can't be the first package to have produced a
python C binding, surely there is some guidance already?

Finally, awkward as it is, if we don't even have a common design intent
I can't support blocking 4.7 on this.  A rush really isn't good for
this kind of thing. 


Andrew Bartlett

Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

More information about the samba-technical mailing list