Le Thu, 22 Oct 2009 14:02:53 -0500, Aaron Griffin a écrit :

On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis wrote:

...

On Tue, 20 Oct 2009 09:48:58 +1000, Allan McRae 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.

Did you mean for this to be post_install? This should be done on remove, if I'm not mistaken, as the pyo files are actually a good thing

No, I meant that to be post_install, because that way: - Pacman will track the .pyo files because they are in the package (as empty text files), so they will be deleted on removal. - The .pyo files will be deleted after install so I think they will be re-generated at runtime. This means there will always be generated for the right architecture and Python version. By the way I think you can do the same for .pyc files. -- catwell

Le Thu, 22 Oct 2009 16:13:33 -0500, Aaron Griffin a écrit :

...

...

...

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.

Did you mean for this to be post_install? This should be done on remove, if I'm not mistaken, as the pyo files are actually a good thing

No, I meant that to be post_install, because that way:

 - Pacman will track the .pyo files because they are in the package (as empty text files), so they will be deleted on removal.

 - The .pyo files will be deleted after install so I think they will be re-generated at runtime. This means there will always be generated for the right architecture and Python version.

By the way I think you can do the same for .pyc files.

This requires that the program has write access to those files, which is generally not the case

This is true. A way to fix it would be to run 'python -O -mcompileall -q /usr/lib/python2.6' as root. That will generate .pyo files for all python packages though, so it means all the packages have to track theirs, otherwise there will be stray files. -- catwell

Hi, the problem is already known and solved: http://bugs.archlinux.org/task/16800 Quite odd that a simple recompiling solves the problem, however I guess that new packages should be available soon. -- Best regards, Karol Babioch