On Thu, Oct 22, 2009 at 4:09 PM, Pierre Chapuis <[email protected]> wrote: > Le Thu, 22 Oct 2009 14:02:53 -0500, > Aaron Griffin <[email protected]> a écrit : > >> On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis <[email protected]> wrote: >> > On Tue, 20 Oct 2009 09:48:58 +1000, >> > Allan McRae <[email protected]> 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
