[arch-dev-public] Strange behaviour of pacman
Hi, I'm having some trouble to understand why pacman left some files on the filesystem, but the package was removed. According to this bug report: http://bugs.archlinux.org/task/16414 pacman left the listed directories and files on the filesystem. I have try to reproduce it and it's true, the files are on the filesystem. My first thought was about the 'emptydirs' option in the PKGBUILD (http://repos.archlinux.org/wsvn/packages/wicd/repos/extra-i686/PKGBUILD), but that wasn't the solution, the files are still there. I can't determine why this happens, any ideas from your side? -Daniel
On Mon, Oct 19, 2009 at 11:45 AM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Hi,
I'm having some trouble to understand why pacman left some files on the filesystem, but the package was removed. According to this bug report: http://bugs.archlinux.org/task/16414 pacman left the listed directories and files on the filesystem. I have try to reproduce it and it's true, the files are on the filesystem. My first thought was about the 'emptydirs' option in the PKGBUILD (http://repos.archlinux.org/wsvn/packages/wicd/repos/extra-i686/PKGBUILD), but that wasn't the solution, the files are still there.
I can't determine why this happens, any ideas from your side?
Files or directories? They are handled quite differently. After you install, can you post the contents of the "files" file from /var/lib/pacman/local/wicd*/files ? -Dan
On Mon, 19 Oct 2009 12:38:40 -0500 Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Oct 19, 2009 at 11:45 AM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Hi,
I'm having some trouble to understand why pacman left some files on the filesystem, but the package was removed. According to this bug report: http://bugs.archlinux.org/task/16414 pacman left the listed directories and files on the filesystem. I have try to reproduce it and it's true, the files are on the filesystem. My first thought was about the 'emptydirs' option in the PKGBUILD (http://repos.archlinux.org/wsvn/packages/wicd/repos/extra-i686/PKGBUILD), but that wasn't the solution, the files are still there.
I can't determine why this happens, any ideas from your side?
Files or directories? They are handled quite differently.
After you install, can you post the contents of the "files" file from /var/lib/pacman/local/wicd*/files ?
Here is the content and at the bottom the left files/directories after removing: -------------------------- $ cat /var/lib/pacman/local/wicd-1.6.2.2-2/files %FILES% etc/ etc/dbus-1/ etc/dbus-1/system.d/ etc/dbus-1/system.d/wicd.conf etc/rc.d/ etc/rc.d/wicd etc/wicd/ etc/wicd/encryption/ etc/wicd/encryption/templates/ etc/wicd/encryption/templates/active etc/wicd/encryption/templates/eap etc/wicd/encryption/templates/eap-tls etc/wicd/encryption/templates/leap etc/wicd/encryption/templates/peap etc/wicd/encryption/templates/peap-tkip etc/wicd/encryption/templates/ttls etc/wicd/encryption/templates/wep-hex etc/wicd/encryption/templates/wep-passphrase etc/wicd/encryption/templates/wep-shared etc/wicd/encryption/templates/wpa etc/wicd/encryption/templates/wpa-psk etc/wicd/scripts/ etc/wicd/scripts/postconnect/ etc/wicd/scripts/postdisconnect/ etc/wicd/scripts/preconnect/ etc/wicd/scripts/predisconnect/ etc/xdg/ etc/xdg/autostart/ etc/xdg/autostart/wicd-tray.desktop usr/ usr/bin/ usr/bin/wicd-client usr/bin/wicd-curses usr/lib/ usr/lib/pm-utils/ usr/lib/pm-utils/sleep.d/ usr/lib/pm-utils/sleep.d/55wicd usr/lib/python2.6/ usr/lib/python2.6/site-packages/ usr/lib/python2.6/site-packages/Wicd-1.6.2.2-py2.6.egg-info usr/lib/python2.6/site-packages/wicd/ usr/lib/python2.6/site-packages/wicd/__init__.py usr/lib/python2.6/site-packages/wicd/__init__.pyc usr/lib/python2.6/site-packages/wicd/backend.py usr/lib/python2.6/site-packages/wicd/backend.pyc usr/lib/python2.6/site-packages/wicd/configmanager.py usr/lib/python2.6/site-packages/wicd/configmanager.pyc usr/lib/python2.6/site-packages/wicd/dbusmanager.py usr/lib/python2.6/site-packages/wicd/dbusmanager.pyc usr/lib/python2.6/site-packages/wicd/gui.py usr/lib/python2.6/site-packages/wicd/gui.pyc usr/lib/python2.6/site-packages/wicd/guiutil.py usr/lib/python2.6/site-packages/wicd/guiutil.pyc usr/lib/python2.6/site-packages/wicd/logfile.py usr/lib/python2.6/site-packages/wicd/logfile.pyc usr/lib/python2.6/site-packages/wicd/misc.py usr/lib/python2.6/site-packages/wicd/misc.pyc usr/lib/python2.6/site-packages/wicd/netentry.py usr/lib/python2.6/site-packages/wicd/netentry.pyc usr/lib/python2.6/site-packages/wicd/networking.py usr/lib/python2.6/site-packages/wicd/networking.pyc usr/lib/python2.6/site-packages/wicd/prefs.py usr/lib/python2.6/site-packages/wicd/prefs.pyc usr/lib/python2.6/site-packages/wicd/translations.py usr/lib/python2.6/site-packages/wicd/translations.pyc usr/lib/python2.6/site-packages/wicd/wnettools.py usr/lib/python2.6/site-packages/wicd/wnettools.pyc usr/lib/python2.6/site-packages/wicd/wpath.py usr/lib/python2.6/site-packages/wicd/wpath.pyc usr/lib/wicd/ usr/lib/wicd/__init__.py usr/lib/wicd/autoconnect.py usr/lib/wicd/backend.py usr/lib/wicd/backends/ usr/lib/wicd/backends/be-external.py usr/lib/wicd/backends/be-ioctl.py usr/lib/wicd/configmanager.py usr/lib/wicd/configscript.py usr/lib/wicd/configscript_curses.py usr/lib/wicd/curses_misc.py usr/lib/wicd/dbusmanager.py usr/lib/wicd/gui.py usr/lib/wicd/guiutil.py usr/lib/wicd/logfile.py usr/lib/wicd/misc.py usr/lib/wicd/monitor.py usr/lib/wicd/netentry.py usr/lib/wicd/netentry_curses.py usr/lib/wicd/networking.py usr/lib/wicd/prefs.py usr/lib/wicd/prefs_curses.py usr/lib/wicd/suspend.py usr/lib/wicd/translations.py usr/lib/wicd/wicd-client.py usr/lib/wicd/wicd-curses.py usr/lib/wicd/wicd-daemon.py usr/lib/wicd/wnettools.py usr/lib/wicd/wpath.py usr/sbin/ usr/sbin/wicd usr/share/ usr/share/applications/ usr/share/applications/wicd.desktop usr/share/doc/ usr/share/doc/wicd/ usr/share/doc/wicd/AUTHORS usr/share/doc/wicd/CHANGES usr/share/doc/wicd/INSTALL usr/share/doc/wicd/LICENSE usr/share/doc/wicd/README usr/share/icons/ usr/share/icons/hicolor/ usr/share/icons/hicolor/128x128/ usr/share/icons/hicolor/128x128/apps/ usr/share/icons/hicolor/128x128/apps/wicd-client.png usr/share/icons/hicolor/16x16/ usr/share/icons/hicolor/16x16/apps/ usr/share/icons/hicolor/16x16/apps/wicd-client.png usr/share/icons/hicolor/192x192/ usr/share/icons/hicolor/192x192/apps/ usr/share/icons/hicolor/192x192/apps/wicd-client.png usr/share/icons/hicolor/22x22/ usr/share/icons/hicolor/22x22/apps/ usr/share/icons/hicolor/22x22/apps/wicd-client.png usr/share/icons/hicolor/24x24/ usr/share/icons/hicolor/24x24/apps/ usr/share/icons/hicolor/24x24/apps/wicd-client.png usr/share/icons/hicolor/32x32/ usr/share/icons/hicolor/32x32/apps/ usr/share/icons/hicolor/32x32/apps/wicd-client.png usr/share/icons/hicolor/36x36/ usr/share/icons/hicolor/36x36/apps/ usr/share/icons/hicolor/36x36/apps/wicd-client.png usr/share/icons/hicolor/48x48/ usr/share/icons/hicolor/48x48/apps/ usr/share/icons/hicolor/48x48/apps/wicd-client.png usr/share/icons/hicolor/64x64/ usr/share/icons/hicolor/64x64/apps/ usr/share/icons/hicolor/64x64/apps/wicd-client.png usr/share/icons/hicolor/72x72/ usr/share/icons/hicolor/72x72/apps/ usr/share/icons/hicolor/72x72/apps/wicd-client.png usr/share/icons/hicolor/96x96/ usr/share/icons/hicolor/96x96/apps/ usr/share/icons/hicolor/96x96/apps/wicd-client.png usr/share/icons/hicolor/scalable/ usr/share/icons/hicolor/scalable/apps/ usr/share/icons/hicolor/scalable/apps/wicd-client.svg usr/share/locale/ usr/share/locale/ar_EG/ usr/share/locale/ar_EG/LC_MESSAGES/ usr/share/locale/ar_EG/LC_MESSAGES/wicd.mo usr/share/locale/bg/ usr/share/locale/bg/LC_MESSAGES/ usr/share/locale/bg/LC_MESSAGES/wicd.mo usr/share/locale/ca/ usr/share/locale/ca/LC_MESSAGES/ usr/share/locale/ca/LC_MESSAGES/wicd.mo usr/share/locale/cs/ usr/share/locale/cs/LC_MESSAGES/ usr/share/locale/cs/LC_MESSAGES/wicd.mo usr/share/locale/da/ usr/share/locale/da/LC_MESSAGES/ usr/share/locale/da/LC_MESSAGES/wicd.mo usr/share/locale/de/ usr/share/locale/de/LC_MESSAGES/ usr/share/locale/de/LC_MESSAGES/wicd.mo usr/share/locale/de_DE/ usr/share/locale/de_DE/LC_MESSAGES/ usr/share/locale/de_DE/LC_MESSAGES/wicd.mo usr/share/locale/el/ usr/share/locale/el/LC_MESSAGES/ usr/share/locale/el/LC_MESSAGES/wicd.mo usr/share/locale/eo/ usr/share/locale/eo/LC_MESSAGES/ usr/share/locale/eo/LC_MESSAGES/wicd.mo usr/share/locale/es/ usr/share/locale/es/LC_MESSAGES/ usr/share/locale/es/LC_MESSAGES/wicd.mo usr/share/locale/es_AR/ usr/share/locale/es_AR/LC_MESSAGES/ usr/share/locale/es_AR/LC_MESSAGES/wicd.mo usr/share/locale/es_CL/ usr/share/locale/es_CL/LC_MESSAGES/ usr/share/locale/es_CL/LC_MESSAGES/wicd.mo usr/share/locale/es_ES/ usr/share/locale/es_ES/LC_MESSAGES/ usr/share/locale/es_ES/LC_MESSAGES/wicd.mo usr/share/locale/es_GT/ usr/share/locale/es_GT/LC_MESSAGES/ usr/share/locale/es_GT/LC_MESSAGES/wicd.mo usr/share/locale/es_MX/ usr/share/locale/es_MX/LC_MESSAGES/ usr/share/locale/es_MX/LC_MESSAGES/wicd.mo usr/share/locale/es_NI/ usr/share/locale/es_NI/LC_MESSAGES/ usr/share/locale/es_NI/LC_MESSAGES/wicd.mo usr/share/locale/es_VE/ usr/share/locale/es_VE/LC_MESSAGES/ usr/share/locale/es_VE/LC_MESSAGES/wicd.mo usr/share/locale/et/ usr/share/locale/et/LC_MESSAGES/ usr/share/locale/et/LC_MESSAGES/wicd.mo usr/share/locale/eu/ usr/share/locale/eu/LC_MESSAGES/ usr/share/locale/eu/LC_MESSAGES/wicd.mo usr/share/locale/fa/ usr/share/locale/fa/LC_MESSAGES/ usr/share/locale/fa/LC_MESSAGES/wicd.mo usr/share/locale/fi/ usr/share/locale/fi/LC_MESSAGES/ usr/share/locale/fi/LC_MESSAGES/wicd.mo usr/share/locale/fr/ usr/share/locale/fr/LC_MESSAGES/ usr/share/locale/fr/LC_MESSAGES/wicd.mo usr/share/locale/fr_CA/ usr/share/locale/fr_CA/LC_MESSAGES/ usr/share/locale/fr_CA/LC_MESSAGES/wicd.mo usr/share/locale/gl/ usr/share/locale/gl/LC_MESSAGES/ usr/share/locale/gl/LC_MESSAGES/wicd.mo usr/share/locale/he/ usr/share/locale/he/LC_MESSAGES/ usr/share/locale/he/LC_MESSAGES/wicd.mo usr/share/locale/hu/ usr/share/locale/hu/LC_MESSAGES/ usr/share/locale/hu/LC_MESSAGES/wicd.mo usr/share/locale/id/ usr/share/locale/id/LC_MESSAGES/ usr/share/locale/id/LC_MESSAGES/wicd.mo usr/share/locale/it/ usr/share/locale/it/LC_MESSAGES/ usr/share/locale/it/LC_MESSAGES/wicd.mo usr/share/locale/it_IT/ usr/share/locale/it_IT/LC_MESSAGES/ usr/share/locale/it_IT/LC_MESSAGES/wicd.mo usr/share/locale/ja/ usr/share/locale/ja/LC_MESSAGES/ usr/share/locale/ja/LC_MESSAGES/wicd.mo usr/share/locale/ka/ usr/share/locale/ka/LC_MESSAGES/ usr/share/locale/ka/LC_MESSAGES/wicd.mo usr/share/locale/kk/ usr/share/locale/kk/LC_MESSAGES/ usr/share/locale/kk/LC_MESSAGES/wicd.mo usr/share/locale/ko/ usr/share/locale/ko/LC_MESSAGES/ usr/share/locale/ko/LC_MESSAGES/wicd.mo usr/share/locale/lt/ usr/share/locale/lt/LC_MESSAGES/ usr/share/locale/lt/LC_MESSAGES/wicd.mo usr/share/locale/lv/ usr/share/locale/lv/LC_MESSAGES/ usr/share/locale/lv/LC_MESSAGES/wicd.mo usr/share/locale/ml/ usr/share/locale/ml/LC_MESSAGES/ usr/share/locale/ml/LC_MESSAGES/wicd.mo usr/share/locale/nl/ usr/share/locale/nl/LC_MESSAGES/ usr/share/locale/nl/LC_MESSAGES/wicd.mo usr/share/locale/nl_NL/ usr/share/locale/nl_NL/LC_MESSAGES/ usr/share/locale/nl_NL/LC_MESSAGES/wicd.mo usr/share/locale/no/ usr/share/locale/no/LC_MESSAGES/ usr/share/locale/no/LC_MESSAGES/wicd.mo usr/share/locale/pl/ usr/share/locale/pl/LC_MESSAGES/ usr/share/locale/pl/LC_MESSAGES/wicd.mo usr/share/locale/pt/ usr/share/locale/pt/LC_MESSAGES/ usr/share/locale/pt/LC_MESSAGES/wicd.mo usr/share/locale/pt_BR/ usr/share/locale/pt_BR/LC_MESSAGES/ usr/share/locale/pt_BR/LC_MESSAGES/wicd.mo usr/share/locale/ro/ usr/share/locale/ro/LC_MESSAGES/ usr/share/locale/ro/LC_MESSAGES/wicd.mo usr/share/locale/ru/ usr/share/locale/ru/LC_MESSAGES/ usr/share/locale/ru/LC_MESSAGES/wicd.mo usr/share/locale/ru_RU/ usr/share/locale/ru_RU/LC_MESSAGES/ usr/share/locale/ru_RU/LC_MESSAGES/wicd.mo usr/share/locale/sk/ usr/share/locale/sk/LC_MESSAGES/ usr/share/locale/sk/LC_MESSAGES/wicd.mo usr/share/locale/sl/ usr/share/locale/sl/LC_MESSAGES/ usr/share/locale/sl/LC_MESSAGES/wicd.mo usr/share/locale/sr/ usr/share/locale/sr/LC_MESSAGES/ usr/share/locale/sr/LC_MESSAGES/wicd.mo usr/share/locale/sv/ usr/share/locale/sv/LC_MESSAGES/ usr/share/locale/sv/LC_MESSAGES/wicd.mo usr/share/locale/te/ usr/share/locale/te/LC_MESSAGES/ usr/share/locale/te/LC_MESSAGES/wicd.mo usr/share/locale/tr/ usr/share/locale/tr/LC_MESSAGES/ usr/share/locale/tr/LC_MESSAGES/wicd.mo usr/share/locale/uk/ usr/share/locale/uk/LC_MESSAGES/ usr/share/locale/uk/LC_MESSAGES/wicd.mo usr/share/locale/vi/ usr/share/locale/vi/LC_MESSAGES/ usr/share/locale/vi/LC_MESSAGES/wicd.mo usr/share/locale/zh_CN/ usr/share/locale/zh_CN/LC_MESSAGES/ usr/share/locale/zh_CN/LC_MESSAGES/wicd.mo usr/share/locale/zh_HK/ usr/share/locale/zh_HK/LC_MESSAGES/ usr/share/locale/zh_HK/LC_MESSAGES/wicd.mo usr/share/locale/zh_TW/ usr/share/locale/zh_TW/LC_MESSAGES/ usr/share/locale/zh_TW/LC_MESSAGES/wicd.mo usr/share/man/ usr/share/man/man1/ usr/share/man/man1/wicd-client.1.gz usr/share/man/man5/ usr/share/man/man5/wicd-manager-settings.conf.5.gz usr/share/man/man5/wicd-wired-settings.conf.5.gz usr/share/man/man5/wicd-wireless-settings.conf.5.gz usr/share/man/man8/ usr/share/man/man8/wicd-curses.8.gz usr/share/man/man8/wicd.8.gz usr/share/pixmaps/ usr/share/pixmaps/wicd/ usr/share/pixmaps/wicd/bad-signal-lock.png usr/share/pixmaps/wicd/bad-signal.png usr/share/pixmaps/wicd/both-bad-signal-lock.png usr/share/pixmaps/wicd/both-bad-signal.png usr/share/pixmaps/wicd/both-good-signal-lock.png usr/share/pixmaps/wicd/both-good-signal.png usr/share/pixmaps/wicd/both-high-signal-lock.png usr/share/pixmaps/wicd/both-high-signal.png usr/share/pixmaps/wicd/both-low-signal-lock.png usr/share/pixmaps/wicd/both-low-signal.png usr/share/pixmaps/wicd/good-signal-lock.png usr/share/pixmaps/wicd/good-signal.png usr/share/pixmaps/wicd/high-signal-lock.png usr/share/pixmaps/wicd/high-signal.png usr/share/pixmaps/wicd/idle-bad-signal-lock.png usr/share/pixmaps/wicd/idle-bad-signal.png usr/share/pixmaps/wicd/idle-good-signal-lock.png usr/share/pixmaps/wicd/idle-good-signal.png usr/share/pixmaps/wicd/idle-high-signal-lock.png usr/share/pixmaps/wicd/idle-high-signal.png usr/share/pixmaps/wicd/idle-low-signal-lock.png usr/share/pixmaps/wicd/idle-low-signal.png usr/share/pixmaps/wicd/low-signal-lock.png usr/share/pixmaps/wicd/low-signal.png usr/share/pixmaps/wicd/no-signal.png usr/share/pixmaps/wicd/receiving-bad-signal-lock.png usr/share/pixmaps/wicd/receiving-bad-signal.png usr/share/pixmaps/wicd/receiving-good-signal-lock.png usr/share/pixmaps/wicd/receiving-good-signal.png usr/share/pixmaps/wicd/receiving-high-signal-lock.png usr/share/pixmaps/wicd/receiving-high-signal.png usr/share/pixmaps/wicd/receiving-low-signal-lock.png usr/share/pixmaps/wicd/receiving-low-signal.png usr/share/pixmaps/wicd/signal-100.png usr/share/pixmaps/wicd/signal-25.png usr/share/pixmaps/wicd/signal-50.png usr/share/pixmaps/wicd/signal-75.png usr/share/pixmaps/wicd/transmitting-bad-signal-lock.png usr/share/pixmaps/wicd/transmitting-bad-signal.png usr/share/pixmaps/wicd/transmitting-good-signal-lock.png usr/share/pixmaps/wicd/transmitting-good-signal.png usr/share/pixmaps/wicd/transmitting-high-signal-lock.png usr/share/pixmaps/wicd/transmitting-high-signal.png usr/share/pixmaps/wicd/transmitting-low-signal-lock.png usr/share/pixmaps/wicd/transmitting-low-signal.png usr/share/pixmaps/wicd/wired-gui.svg usr/share/pixmaps/wicd/wired.png usr/share/wicd/ usr/share/wicd/scripts/ usr/share/wicd/scripts/50-wicd-suspend.sh usr/share/wicd/scripts/80-wicd-connect.sh usr/share/wicd/wicd.glade var/ var/lib/ var/lib/wicd/ var/lib/wicd/WHEREAREMYFILES var/lib/wicd/configurations/ var/log/ var/log/wicd/ %BACKUP% etc/wicd/encryption/templates/active 7f5ffbaf034bdbc09344c19fe9752a75 -------------------------- These files are left after removing: $ ls -la /usr/lib/python2.6/site-packages/wicd/ total 160 drwxr-xr-x 2 root root 4096 2009-10-19 19:53 . drwxr-xr-x 61 root root 12288 2009-10-19 19:53 .. -rw-r--r-- 1 root root 136 2009-10-19 18:39 __init__.pyo -rw-r--r-- 1 root root 4571 2009-10-19 18:39 backend.pyo -rw-r--r-- 1 root root 5256 2009-10-19 18:39 configmanager.pyo -rw-r--r-- 1 root root 3586 2009-10-19 18:39 dbusmanager.pyo -rw-r--r-- 1 root root 6904 2009-10-19 18:39 logfile.pyo -rw-r--r-- 1 root root 17703 2009-10-19 18:39 misc.pyo -rw-r--r-- 1 root root 39230 2009-10-19 18:39 networking.pyo -rw-r--r-- 1 root root 47605 2009-10-19 18:39 wnettools.pyo $ ls -laR /usr/lib/wicd/ /usr/lib/wicd/: total 168 drwxr-xr-x 3 root root 4096 2009-10-19 19:53 . drwxr-xr-x 223 root root 159744 2009-10-19 18:39 .. drwxr-xr-x 2 root root 4096 2009-10-19 19:53 backends /usr/lib/wicd/backends: total 32 drwxr-xr-x 2 root root 4096 2009-10-19 19:53 . drwxr-xr-x 3 root root 4096 2009-10-19 19:53 .. -rw-r--r-- 1 root root 3218 2009-10-19 18:39 be-external.pyo -rw-r--r-- 1 root root 18200 2009-10-19 18:39 be-ioctl.pyo -rw-r--r-- 1 root root 2652 2009-10-19 18:39 wpath.pyo $ ls -la /var/log/wicd total 12 drwxr-xr-x 2 root root 4096 2009-10-19 18:39 . drwxr-xr-x 12 root root 4096 2009-10-19 18:39 .. -rw------- 1 root root 1764 2009-10-19 18:39 wicd.log As I can see now, these are .pyo files. Are they generate at runtime or something like that? They are not in the package.
As I can see now, these are .pyo files. Are they generate at runtime or something like that? They are not in the package.
.pyo files are, I believe, "optimized" python files generated during runtime.
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard <twillard2@gmail.com> wrote:
As I can see now, these are .pyo files. Are they generate at runtime or something like that? They are not in the package.
.pyo files are, I believe, "optimized" python files generated during runtime.
I beleiie so too. I think there was a thread about how to deal with these files. I think the info is in a wiki article about python packaging guidelines. The other remaining file is wicd.log wich is generated at runtime too.
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard <twillard2@gmail.com> wrote:
As I can see now, these are .pyo files. Are they generate at runtime or something like that? They are not in the package.
.pyo files are, I believe, "optimized" python files generated during runtime.
I beleiie so too. I think there was a thread about how to deal with these files. I think the info is in a wiki article about python packaging guidelines. The other remaining file is wicd.log wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it. The log file is acceptable, but the pyo files are annyoing.
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard <twillard2@gmail.com> wrote:
As I can see now, these are .pyo files. Are they generate at runtime or something like that? They are not in the package.
.pyo files are, I believe, "optimized" python files generated during runtime.
I beleiie so too. I think there was a thread about how to deal with these files. I think the info is in a wiki article about python packaging guidelines. The other remaining file is wicd.log wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it.
The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir). I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like: PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard <twillard2@gmail.com> wrote:
As I can see now, these are .pyo files. Are they generate at runtime or something like that? They are not in the package.
.pyo files are, I believe, "optimized" python files generated during runtime.
I beleiie so too. I think there was a thread about how to deal with these files. I think the info is in a wiki article about python packaging guidelines. The other remaining file is wicd.log wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it.
The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard <twillard2@gmail.com> wrote:
As I can see now, these are .pyo files. Are they generate at runtime or something like that? They are not in the package.
.pyo files are, I believe, "optimized" python files generated during runtime.
I beleiie so too. I think there was a thread about how to deal with these files. I think the info is in a wiki article about python packaging guidelines. The other remaining file is wicd.log wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it.
The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard <twillard2@gmail.com> wrote:
> As I can see now, these are .pyo files. Are they generate at > runtime or something like that? They are not in the package. >
.pyo files are, I believe, "optimized" python files generated during runtime.
I beleiie so too. I think there was a thread about how to deal with these files. I think the info is in a wiki article about python packaging guidelines. The other remaining file is wicd.log wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it.
The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard <twillard2@gmail.com> wrote: >> As I can see now, these are .pyo files. Are they generate at >> runtime or something like that? They are not in the package. >> > > .pyo files are, I believe, "optimized" python files generated > during runtime. >
I beleiie so too. I think there was a thread about how to deal with these files. I think the info is in a wiki article about python packaging guidelines. The other remaining file is wicd.log wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it.
The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this python setup.py install --optimize=1 ...other args...
On Mon, 19 Oct 2009 14:56:02 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
> On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard > <twillard2@gmail.com> wrote: > >> As I can see now, these are .pyo files. Are they generate > >> at runtime or something like that? They are not in the > >> package. > >> > > > > .pyo files are, I believe, "optimized" python files > > generated during runtime. > > > > I beleiie so too. I think there was a thread about how to > deal with these files. I think the info is in a wiki article > about python packaging guidelines. The other remaining file > is wicd.log wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it.
The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
But then you have to track the files every rebuild, if they really exists or not.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this
python setup.py install --optimize=1 ...other args...
This is the correct parameter: --optimize (-O) also compile with optimization: -O1 for "python -O", -O2 for "python -OO", and -O0 to disable [default: -O0] But as the parameter mentioned, it is disabled by default. :(
On Mon, Oct 19, 2009 at 3:00 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:56:02 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote: > On Mon, 19 Oct 2009 14:45:20 -0400 > Eric Bélanger <snowmaniscool@gmail.com> wrote: > >> On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard >> <twillard2@gmail.com> wrote: >> >> As I can see now, these are .pyo files. Are they generate >> >> at runtime or something like that? They are not in the >> >> package. >> >> >> > >> > .pyo files are, I believe, "optimized" python files >> > generated during runtime. >> > >> >> I beleiie so too. I think there was a thread about how to >> deal with these files. I think the info is in a wiki article >> about python packaging guidelines. The other remaining file >> is wicd.log wich is generated at runtime too. > > I have nothing found about those files. The article about > python package guidelines is very short. Nothing special about > it. > > The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
But then you have to track the files every rebuild, if they really exists or not.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this
python setup.py install --optimize=1 ...other args...
This is the correct parameter:
--optimize (-O) also compile with optimization: -O1 for "python -O", -O2 for "python -OO", and -O0 to disable [default: -O0]
But as the parameter mentioned, it is disabled by default. :(
Yeah, we're just going to have to do that when we run setup.py scripts, in order to track the .pyo files.
On Mon, Oct 19, 2009 at 3:56 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:45:20 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
> On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard > <twillard2@gmail.com> wrote: > >> As I can see now, these are .pyo files. Are they generate at > >> runtime or something like that? They are not in the package. > >> > > > > .pyo files are, I believe, "optimized" python files generated > > during runtime. > > > > I beleiie so too. I think there was a thread about how to deal > with these files. I think the info is in a wiki article about > python packaging guidelines. The other remaining file is wicd.log > wich is generated at runtime too.
I have nothing found about those files. The article about python package guidelines is very short. Nothing special about it.
The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this
python setup.py install --optimize=1 ...other args...
yeah, just found that here: http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy ML thread I refered to earlier: http://mailman.archlinux.org/pipermail/arch-dev-public/2008-December/009525....
On Mon, 19 Oct 2009 16:02:15 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:56 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote: > On Mon, 19 Oct 2009 14:45:20 -0400 > Eric Bélanger <snowmaniscool@gmail.com> wrote: > >> On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard >> <twillard2@gmail.com> wrote: >> >> As I can see now, these are .pyo files. Are they generate >> >> at runtime or something like that? They are not in the >> >> package. >> >> >> > >> > .pyo files are, I believe, "optimized" python files >> > generated during runtime. >> > >> >> I beleiie so too. I think there was a thread about how to >> deal with these files. I think the info is in a wiki >> article about python packaging guidelines. The other >> remaining file is wicd.log wich is generated at runtime too. > > I have nothing found about those files. The article about > python package guidelines is very short. Nothing special > about it. > > The log file is acceptable, but the pyo files are annyoing.
I imagine that this only happens with apps run as root (or have write permissions to their install dir).
I think the best thing, for the time being, is to do this in a pre_remove (so you have access to pacman -Ql at that time) and do something like:
PKGNAME=wicd pre_remove () { for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then rm "$pyo" fi done }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this
python setup.py install --optimize=1 ...other args...
yeah, just found that here: http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
Why wasn't that added to the "official" Python Packaging Policy here: http://wiki.archlinux.org/index.php/Python_Package_Guidelines I will change that in the next package version of wicd. I just committed the other "fix", don't want to release the next package right now. Have to remember that page.
ML thread I refered to earlier: http://mailman.archlinux.org/pipermail/arch-dev-public/2008-December/009525....
Long time ago ;)
On Mon, Oct 19, 2009 at 3:08 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 16:02:15 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:56 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 14:08:33 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann > <daniel.isenmann@gmx.de> wrote: > > On Mon, 19 Oct 2009 14:45:20 -0400 > > Eric Bélanger <snowmaniscool@gmail.com> wrote: > > > >> On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard > >> <twillard2@gmail.com> wrote: > >> >> As I can see now, these are .pyo files. Are they generate > >> >> at runtime or something like that? They are not in the > >> >> package. > >> >> > >> > > >> > .pyo files are, I believe, "optimized" python files > >> > generated during runtime. > >> > > >> > >> I beleiie so too. I think there was a thread about how to > >> deal with these files. I think the info is in a wiki > >> article about python packaging guidelines. The other > >> remaining file is wicd.log wich is generated at runtime too. > > > > I have nothing found about those files. The article about > > python package guidelines is very short. Nothing special > > about it. > > > > The log file is acceptable, but the pyo files are annyoing. > > I imagine that this only happens with apps run as root (or have > write permissions to their install dir). > > I think the best thing, for the time being, is to do this in a > pre_remove (so you have access to pacman -Ql at that time) and > do something like: > > PKGNAME=wicd > pre_remove () { > for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed > 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then > rm "$pyo" > fi > done > }
Ok, I will do it this way, but shouldn't we have a better solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this
python setup.py install --optimize=1 ...other args...
yeah, just found that here: http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
Why wasn't that added to the "official" Python Packaging Policy here: http://wiki.archlinux.org/index.php/Python_Package_Guidelines
I will change that in the next package version of wicd. I just committed the other "fix", don't want to release the next package right now. Have to remember that page.
Added it :)
On Mon, 19 Oct 2009 15:10:24 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:08 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 16:02:15 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:56 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote: > On Mon, 19 Oct 2009 14:08:33 -0500 > Aaron Griffin <aaronmgriffin@gmail.com> wrote: > >> On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann >> <daniel.isenmann@gmx.de> wrote: >> > On Mon, 19 Oct 2009 14:45:20 -0400 >> > Eric Bélanger <snowmaniscool@gmail.com> wrote: >> > >> >> On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard >> >> <twillard2@gmail.com> wrote: >> >> >> As I can see now, these are .pyo files. Are they >> >> >> generate at runtime or something like that? They are >> >> >> not in the package. >> >> >> >> >> > >> >> > .pyo files are, I believe, "optimized" python files >> >> > generated during runtime. >> >> > >> >> >> >> I beleiie so too. I think there was a thread about how to >> >> deal with these files. I think the info is in a wiki >> >> article about python packaging guidelines. The other >> >> remaining file is wicd.log wich is generated at runtime >> >> too. >> > >> > I have nothing found about those files. The article about >> > python package guidelines is very short. Nothing special >> > about it. >> > >> > The log file is acceptable, but the pyo files are annyoing. >> >> I imagine that this only happens with apps run as root (or >> have write permissions to their install dir). >> >> I think the best thing, for the time being, is to do this in >> a pre_remove (so you have access to pacman -Ql at that time) >> and do something like: >> >> PKGNAME=wicd >> pre_remove () { >> for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed >> 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then >> rm "$pyo" >> fi >> done >> } > > Ok, I will do it this way, but shouldn't we have a better > solution for this for the future?
Well, the only sane way to do it would be to make sure pacman tracks the .pyo files by generating them as part of the package creation process, but I don't even know if that's possible
it's possible. Just create empty files with the same name with 'touch' in the build function.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this
python setup.py install --optimize=1 ...other args...
yeah, just found that here: http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
Why wasn't that added to the "official" Python Packaging Policy here: http://wiki.archlinux.org/index.php/Python_Package_Guidelines
I will change that in the next package version of wicd. I just committed the other "fix", don't want to release the next package right now. Have to remember that page.
Added it :)
The only problem is, that architecture 'any' doesn't work anymore with this install option. But I think that this problem doesn't affect so much packages to worry about, I think.
On Mon, Oct 19, 2009 at 3:12 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 15:10:24 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:08 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Mon, 19 Oct 2009 16:02:15 -0400 Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:56 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote: > On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann > <daniel.isenmann@gmx.de> wrote: >> On Mon, 19 Oct 2009 14:08:33 -0500 >> Aaron Griffin <aaronmgriffin@gmail.com> wrote: >> >>> On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann >>> <daniel.isenmann@gmx.de> wrote: >>> > On Mon, 19 Oct 2009 14:45:20 -0400 >>> > Eric Bélanger <snowmaniscool@gmail.com> wrote: >>> > >>> >> On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard >>> >> <twillard2@gmail.com> wrote: >>> >> >> As I can see now, these are .pyo files. Are they >>> >> >> generate at runtime or something like that? They are >>> >> >> not in the package. >>> >> >> >>> >> > >>> >> > .pyo files are, I believe, "optimized" python files >>> >> > generated during runtime. >>> >> > >>> >> >>> >> I beleiie so too. I think there was a thread about how to >>> >> deal with these files. I think the info is in a wiki >>> >> article about python packaging guidelines. The other >>> >> remaining file is wicd.log wich is generated at runtime >>> >> too. >>> > >>> > I have nothing found about those files. The article about >>> > python package guidelines is very short. Nothing special >>> > about it. >>> > >>> > The log file is acceptable, but the pyo files are annyoing. >>> >>> I imagine that this only happens with apps run as root (or >>> have write permissions to their install dir). >>> >>> I think the best thing, for the time being, is to do this in >>> a pre_remove (so you have access to pacman -Ql at that time) >>> and do something like: >>> >>> PKGNAME=wicd >>> pre_remove () { >>> for pyo in $(pacman -Qql $PKGNAME | grep \.py$ | sed >>> 's|.py$|.pyo|g'); do if [ -f "$pyo" ]; then >>> rm "$pyo" >>> fi >>> done >>> } >> >> Ok, I will do it this way, but shouldn't we have a better >> solution for this for the future? > > Well, the only sane way to do it would be to make sure pacman > tracks the .pyo files by generating them as part of the package > creation process, but I don't even know if that's possible >
it's possible. Just create empty files with the same name with 'touch' in the build function.
Looks like python -O py_compile.py foo.py will do this. And it looks like setuptools has an --optimize argument. I'd suggest trying this
python setup.py install --optimize=1 ...other args...
yeah, just found that here: http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
Why wasn't that added to the "official" Python Packaging Policy here: http://wiki.archlinux.org/index.php/Python_Package_Guidelines
I will change that in the next package version of wicd. I just committed the other "fix", don't want to release the next package right now. Have to remember that page.
Added it :)
The only problem is, that architecture 'any' doesn't work anymore with this install option. But I think that this problem doesn't affect so much packages to worry about, I think.
Are you saying that the .pyo files are no longer architecture independent? I was under the assumption they were.
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.
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() Allan
participants (7)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Daniel Isenmann
-
Eric Bélanger
-
Jan de Groot
-
Travis Willard