Re: Go (golang) packaging, part 2

[Matthias Klose <doko@debian.org>]

Am 07.02.2013 01:54, schrieb Paul Wise:
> On Thu, Feb 7, 2013 at 8:19 AM, Barry Warsaw wrote:
> 
>> Speaking with many hats on, I think Debian Python has done a very admirable
>> job of integrating the Python ecosystem with Debian.
> 
> One of the pain points for users (I've had folks ask me this
> face-to-face) with that stuff was site-packages vs dist-packages. With
> your various Python hats on, can you explain why not just use
> "packages" instead of "site-packages" and "dist-packages"?

Sure, anything else than "site-packages" would have worked.

> The right
> way (IMO) would have been to put site packages in
> /usr/local/lib/pythonX.Y/packages and dist ones in
> /usr/lib/pythonX.Y/packages. Right now I have
> /usr/local/lib/pythonX.Y/dist-packages and
> /usr/lib/pythonX.Y/dist-packages, why is /usr/local dist-packages
> instead of site-packages? /usr/local is clearly not the location for
> distro installed packages.

This came up several times (e.g. [1], [2]). See [3] for the rationale for the
naming and the extra directories in /usr/local.

> Why did Debian have to invent /usr/share/pyshared and symlink farms in
> /usr/lib/pythonX.Y instead of upstream having something like that in
> the default install and search paths?

Having separate copies of .py files would have been an option. Splitting .so and
.py files across directories not, because having different directories for third
party packages in python2.x can break the import behaviour, does break split-out
debug information, doesn't work for gir files, and more. Please search back the
archives until 2003, if you are really interested in this.

> The location of .pyc files that are built at install time doesn't feel
> FHS-correct to me, /var/cache/python/X.Y/ seems better.

The location is correct if you include these files in the packages. So why
change it if you regenerate them? Byte-compilation and pyshared is only a means
to make pure python code independent of the python version. This is changed in
Python3 upstream [4]. Please address any outstanding issues upstream, then maybe
provide a backport.

> Debian's Python build helper tools are still breeding like rabbits,
> there is a new one in experimental. I guess because the current ones
> dh_python2/dh_python3 don't handle packages that contain only code
> that runs on both python2 and python3 without changes.

I don't have any issue to build packages using dh_python2 and dh_python3. Please
file a bug report if you do have such issues.  It is my understanding that
dh_python2/dh_python3 are stable and should still be available in jessie, but
then using the underlying pybuild system.  If you want to improve the tools,
please do. Sarcasm doesn't do any improvement by itself.  Please join Piotr.

  Matthias

[1] https://lists.debian.org/debian-python/2008/03/msg00021.html
[2] https://lists.debian.org/debian-python/2009/02/msg00002.html
[3] https://lists.debian.org/debian-devel/2009/02/msg00431.html
[4] http://www.python.org/dev/peps/pep-3147/