[arch-dev-public] Python packaging policy

Allan McRae allan at archlinux.org
Thu Dec 18 19:28:48 EST 2008

Aaron Griffin wrote:
> On Thu, Dec 18, 2008 at 6:34 AM, Allan McRae <allan at archlinux.org> wrote:
>> Allan McRae wrote:
>>> Hi all,
>>> A few recent bugs have highlighted issues with how we deal with compiled
>>> versions (.pyo/.pyc) of python (.py) files.    We should probably make a
>>> policy on how these should be handled during packaging.
>>> Given I am the python maintainer, I suppose I should be doing this, but I
>>> am wanting to do some more makepkg/pacman stuff so it would be good if
>>> someone else wants to take the lead on this.
>>> Here is a couple of policies from other distros
>>> Debian: http://www.debian.org/doc/packaging-manuals/python-policy/
>>> Fedora: https://fedoraproject.org/wiki/Packaging/Python
>>> If someone (not necessarily a dev) wants to help out with this, then it
>>> would be much appreciated.
>> And given I have already been asked twice what the best way to start this
>> is, here goes a wiki page to collect ideas on this:
>> http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
> I wish I had something to help here. Do you have anything in mind as
> to how we will actually deal with pyc files on an upgrade (i.e. 2.5 to
> 2.6) ?

Well, the options I see are
1) .pyc/.pyo files are created as part of packaging.  That way we just 
rebuild the package if needed during an upgrade.
2) .pyc/.pyo files are recreated on python/package update.  So, we would 
have a pre_update script that finds all the .pyc/.pyo files, deletes 
them and a post_update script that rebuilds them.  In this option, it 
would be better if .pyc/.pyo files were not part of a package as I don't 
like one package touching another packages files.

I'm heavily leaning towards #1 as I don't like having files on my root 
partition that are not controlled by pacman.  However, that can lead to 
a lot of conflicts during upgrades in the short term...

I haven't thought about this any further than that at the moment.


More information about the arch-dev-public mailing list