Re: [arch-general] [arch-dev-public] Strange behaviour of pacman
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
On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
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.
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
Le Thu, 22 Oct 2009 14:02:53 -0500, Aaron Griffin <aaronmgriffin@gmail.com> a écrit :
On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
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.
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
On Thu, Oct 22, 2009 at 4:09 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
Le Thu, 22 Oct 2009 14:02:53 -0500, Aaron Griffin <aaronmgriffin@gmail.com> a écrit :
On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
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.
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
Le Thu, 22 Oct 2009 16:13:33 -0500, Aaron Griffin <aaronmgriffin@gmail.com> 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, I've just updated my compiz, including compiz-decorator-gtk as I don't use emerald. However after installing the new packages my windows are messed up, as the title bar is missing, although it has been working beforehand. When I try to look up my windows decorator by clicking on the compiz icon, I can't see the "Select window decorator" menu, as it is grey. I've installed emerald in order to check, whether it works with it, and indeed it does. However I don't want to use emerald, so I guess that there is something wrong with the compiz-decorator-gtk package, as it doesn't get recognized by compiz (icon) and therefore isn't applied to any window :(. What can I do about this? What do you propose? Do I have to wait until the package(s) get re-compiled? -- Best regards, Karol Babioch <karol@babioch.de>
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 <karol@babioch.de>
compiz-decorator-gtk 0.8.4-2 solves this problem. -- Best regards, Karol Babioch <karol@babioch.de>
participants (3)
-
Aaron Griffin
-
Karol Babioch
-
Pierre Chapuis