On 2016/01/10 19:13, Alexandr Shadchin wrote: > On Sun, Jan 10, 2016 at 01:26:47PM +0000, Stuart Henderson wrote: > > I don't think PKG_ARCH=* is a good idea - .pyc files aren't identical > > between arches. > > > > My little research: > Python bytecode is portable across platforms, but not really across Python > versions. > > .pyc files contain a timestamp, this explains the difference. > > Structure pyc (py2): > 4 byte - magic > 4 byte - timestamp > other - bytecode (marshal) > > Structure pyc (py3): > 4 byte - magic > 4 byte - timestamp > 4 byte - size > other - bytecode (marshal) > > I check amd64 and i386, the files are identical. > > Can anyone have more information?
I can't find it now but I'm pretty sure when we looked into this before we found that there were differences depending on the arch creating the file, though the generated files could be used on either arch. I'm not sure if it was due to word length or endianness or something else. But given that we already have problems with pyc files with pkg_add -u I don't want to add any more opportunities for problems. And in any event doing this on a per-port basis doesn't really make sense.. (Specific known problem with pkg_add: some pyc files are generated with one timestamp, but the py file is actually installed with a *different* timestamp. This is the cause of the "email/mime" update problem that people see from time to time.) AFAIK the last time anyone used PKG_ARCH=* as an optimization when building packages was when I last built packages for an arm release. They're not useful in typical snapshot builds (only if a fast arch build is done from the same source tree as a slower arch build), and even for a normal release build they're problematic (there have been some things marked with PKG_ARCH=* that shouldn't have been), so at this point I'd lean towards removing PKG_ARCH support completely.. (If we do that, packages using it, e.g. much of p5-*, will need bumps).
