On Tue, 20 Oct 2009 09:48:58 +1000, Allan McRae <allan@archlinux.org> wrote:
Jan de Groot wrote:
On Mon, 2009-10-19 at 15:18 -0500, Aaron Griffin wrote:
Are you saying that the .pyo files are no longer architecture independent? I was under the assumption they were.
Actually, they're even python-version specific. Updating python could break the precompiled .pyo files.
And this whole issue was a fairly major source of headaches during the python-2.6 transition... which is why I started making the python packaging policy to deal with them, although that obviously was never finished with (in fact, I had never seen the comment with --optimize=1 in it).
Now my main concern about all of this is that .pyc and .pyo files used to contain full paths to where they were created. That meant they need to be created on the users system and not during the packaging stage. I have not confirmed if this is still the case.
So the best way to deal with them seems to be: 1) touch them during packaging 2) generate them during post_install()
I have found a way to automate that which is, I believe, not PKGBUILD-dependant. Here's what I do in the PKGBUILD: [...] install="pyo_remover.install" [...] build() { [...] # Take care of .pyo files cd $pkgdir echo "post_install() {" > $startdir/$install for _i in $(find . -name '*.pyo'); do echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install echo > "$_i" done echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >> $startdir/$install } pyo_remover.install can be anything, even an empty file. For packages that need a .install file this has to be adapted. Does this look like a good way to solve the problem? I know the way I do it for now is kind of ugly, but I think it could be much cleaner if the same kind of thing was done directly by makepkg. -- catwell