Johannes Meixner napsal(a):

By the way:

Isn't there a general problem with "python files strewn all over the system"?

Well, yes, that's why i wrote it's bad packaging. But it's a minor problem. Python will work with it (unless the misplaced thing is a python module, in which case python won't be able to find and import it without some hassle) and ordinary user will not notice. This might change when Python is accepted into LSB, because there will probably be some restriction on .py files placement.

How does Python deal with .py files from whatever personal Python projects in user's home directories? The user has write access so that he gets .pyc or .pyo files stored where his .py files are. What happens if the system admin upgrades to a new major version of Python?

I'm not entirely sure about this, but i think that python will complain and recompile the bytecode files in question. Sadly, i don't have an old enough python anywhere nearby, so i can't test the assumption now.

I think the same problem (perhaps even in a worse shape) exists for whatever third-party Python stuff which gets installed somewhere under /opt/ or /usr/local/. Think about proprietary third-party software which cannot be changed and which exists for more than one SLES version.

Oldest python we support is version 2.2.1 in SLES8, and all new versions since that are at least backwards compatible. So if anyone has a third-party software for python 1.5, too bad for them. But i think that third party vendors would provide python2 compatible packages by now.

I don't know if the Python license allows to have proprietary Python stuff but I think you understand the basic idea behind. http://www.python.org/doc/1.5.1p1/tut/node43.html seems to indicate that at least semi-proprietary Python stuff can exist because it reads: --------------------------------------------------------------- It is possible to have a file called "spam.pyc" (or "spam.pyo" when -O is used) without a module "spam.py" in the same module. This can be used to distribute a library of Python code in a form that is moderately hard to reverse engineer. --------------------------------------------------------------- There could be even "binary-only" third-party Python stuff where no .py files exist. What happens if a system upgrade (e.g. SLES N -> SLES N+1) upgrades Python to a new major version?

The software will no longer work. Users would need to either keep the older python around, or ask the vendor to recompile the package. But the bytecode files will not be deleted.

...

But even more important is that regular user doesn't have write access to wherever the .py files are stored. You would need to run each python program as root first, otherwise python would need to compile the sources every time the program is run.

This has another consequence: It doesn't help not to provide .pyc or .pyo files in the RPM to avoid problems with outdated .pyc or .pyo files if the Python major version changes because when root runs whatever .py files, the matching .pyc or .pyo files are created in any case.

Right.

...

...

I am no Python expert at all and I would be happy if a Python expert could provide some background information. is this background sufficient? ;e)

Yes, it is perfect and I am happy.

glad to read that. regards jan matejek --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org