Arch Linux

I forgot to mention that I use x86_64 and that the most relevant post in the ML is:

http://mailman.archlinux.org/pipermail/arch-dev-public/2009-October/013996.html

I thought the conclusion was that pyc/pyo files should be included in the package...

What is the error message you are getting?

Well, unless there has been further discussion on a non-public list, the final conclusion of the discussion was what you wrote in the email linked above, which is that .pyo/.pyc files have to be generated on the user machine.

There are many ways to deal with it, the one you proposed is to touch them during build() so that they are tracked by Pacman and then generate them during post_install(), but here there is no post_install() and --optimize=1 is used during build().

As for the error message, Pacman complains that these files exist on my system but this is probably my fault because I might have generated them by hand earlier. I can fix it by removing them first or with -Sf if needed.

Also, if the only problem is the absolute paths, a solution is proposed here that might allow to include binary files directly into the package:

www.mail-archive.com/python-list@python.org/msg36945.html

I still don't think it is a good solution because .pyo/.pyc are not guaranteed to be architecture independant forever.

I have looked into this in detail and am currently drafting a python packaging policy. Essentially, every .py file in /usr/lib/python2.6 (maybe others) should also have the corresponding .pyc and .pyo files shipped. Any package with files in that folder needs rebuilt when a new major python version becomes available anyway.

The compile path issue looks to have been fixed quite a while ago. .pyo/.pyc files are architecture independent and that is very unlikely to change.

Anyway, this is not a bug as the package is conflicting with files you generated. Check there are not owned by any package and the -Sf over them. Part of the goal in packaging those files is to prevent issues with such files being left on a users system.

That is what I did. Thanks for the clarification, I have checked using strings and indeed it looks like there are no more compile paths in the binary files.

When you are done with the packaging policy, it would be worth a news on the website or at least a post to aur-general!

Thanks for your work, you can close this as 'not a bug'.