Dne 18.6.2010 09:50, Ludwig Nussel napsal(a):

Why do such packages install files into the python file hierarchy (ie module search path) then?

because that's customary, convenient, and only drawback is this one rpmlint warning if packages installed their private modules into their own hierarchies, they would need to actively maintain knowledge about where they install, which has many drawbacks: - it limits flexibility of python and package install path - the packages themselves need to care about lib/lib64 distinction, or install into /usr/share (which as of now breaks FHS) - they would need to modify their sys.path, which is inconvenient and can cause problems with tools like virtualenv - they would need to express this in their build scripts (distutils install into python hierarchy by default) all in all: for many packages, this is too much trouble for too little gain as for the python naming policy, the wiki page seems pretty clear on that: "All python **modules**, whether pure python or C-based, should be called python-modulename. This policy doesn't apply to end-user applications written in python." (from http://en.opensuse.org/Packaging/Python#Naming_policy ) Emphasis added - the naming policy only applies to python modules, i.e. packages that provide functionality to other python programs. It does not apply to programs that only happen to install into python's hierarchy. If you think that the wording is unclear, or that we need clarifications about what constitutes a "module" and what is "end-user application", any suggestions are welcome. regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Dne 19.6.2010 09:20, Dave Plater napsal(a):

Yes this is vague, if a python module had been likened to a shared lib I would have understood immediately but now I understand after reading over a few times.

i have expanded the "naming policy" section. please let me know if anything is still unclear

I've also stumbled upon the "Fixing python install paths" part of "Packaging/Fixing" and it is clear to me that the packages own install's default was correct in installing the py files to %python_sitelib. This also needs clarification in "Packaging/Python" or a link to the "Packaging/Fixing" part.

i'm not sure what you mean here - can you propose a specific change that would help with your problem? regards m.

Regards Dave P

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Dne 23.6.2010 12:48, Dave Plater napsal(a):

...

Dne 19.6.2010 09:20, Dave Plater napsal(a):

...

Yes this is vague, if a python module had been likened to a shared lib I would have understood immediately but now I understand after reading over a few times.

i have expanded the "naming policy" section. please let me know if anything is still unclear I'm lead to understand that this naming policy only applies to python modules that are designed to be used by programs other than the

On 06/22/2010 08:36 PM, Jan Matejek wrote: package that they came from, is this correct?

yes, pretty much

...

...

I've also stumbled upon the "Fixing python install paths" part of "Packaging/Fixing" and it is clear to me that the packages own install's default was correct in installing the py files to %python_sitelib. This also needs clarification in "Packaging/Python" or a link to the "Packaging/Fixing" part.

i'm not sure what you mean here - can you propose a specific change that would help with your problem?

I'm referring to the correct directory that the python modules from package ffado are installed in. In the package changelog there is mention of :- "All ffado stuff is now in packages getting installed to the official python dirs. Ideally this would allow other apps to use the stuff from us." and the default install directory is %{_libexec}/python%{py_ver}/site-packages. In "Packaging/Fixing" it indicates that this is the preferred directory but "Packaging/Python" isn't clear enough about which is the preferred directory, "Packaging/Fixing" is much clearer and the "File Lists" section should have a link to "Packaging/Fixing".

i'm afraid i'll need a little more explanation than that to properly fix the text - at this point, i don't understand what was your original problem. I don't think that it's a good idea to link to Packaging/Fixing from Packaging/Python - IMHO, much better solution is to expand Packaging/Python and direct Packaging/Fixing into a specific section of it. There is already a section called "File locations" which says that " All python source and bytecode files should go into /usr/lib(64)/pythonX.Y/site-packages, or maybe /usr/lib(64)/yourapp." Do you think that this statement needs more emphasis or clarification? Plus, the overall policy is that "files should generally go wherever upstream installs them, unless that conflicts with some of our policies". Would it help to mention this in the guidelines? thanks m.

Regards Dave P

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hello, On Thu, 24 Jun 2010, Dave Plater wrote:

* %python_sitelib expands to /usr/lib/pythonX.Y/site-packages. This is the install location for platform-independent modules. * %python_sitearch expands to %{_libdir}/pythonX.Y/site-packages, that is, either /usr/lib or /usr/lib64, depending on your architecture. This is the install location for platform-dependent modules.

I'm not sure what a platform dependent python file is, this needs an explanation. All scripts must be noarch, therefore a .py file would go in %python_sitelib, which files would go into %python_sitearch?

Any .so or other binary(!), specifically compiled for a specific arch should go into _sitearch, any non-arch-specific (which includes *.pyc and AFAIK *.pyo, those are version specific, not arch specific) into _sitelib. Just run find $(rpm --eval '%python_sitelib') -name '*.so*' find $(rpm --eval '%python_sitearch') -name '*.so*' If all is well, the first command should output nothing, the latter should output e.g. .../site-packages/Crypto/Cipher/AES.so .../site-packages/Numeric/umath.so .../site-packages/pygame/joystick.so You get the idea? HTH, -dnh -- I refer to garlic as "the element without which life as we know it would be impossible." Personally I believe that the garlic myth was started by vampires as a way of enhancing the flavor of their food. -- Shmuel Metz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 06/18/2010 09:33 AM, Dominique Leuenberger wrote:

...

...

...

On 6/18/2010 at 9:09, Dave Plater wrote:

Hi, after reading replies to my "need help with rpmlint" email to this list, I found the packaging/python wiki and used python macros in the spec file. I'm still confused about the rpmlint warning :- ffado.x86_64: W: python-naming-policy-not-applied /usr/lib64/python2.6/site-packages/ffado/mixer/quatafire.ui This package doesn't respect the naming policy for python packages. Its name should match the regular expression ^python(-|$).

IMHO in this case the warning is a warning and as such is not fatal (otherwise it would be an error, like shlib naming policy).

If you check for example the build log for openSUSE:Tools/osc, you'll see that this has the exact same warning.

As outlined in a previous mail: The naming policy is meant to declare that this is a package providing some goodies for developers coding in python. Something, which I think does not apply to your package (also not to osc), as they are 'end user tools.

It seems a bit silly seeing that the files are under /python%py_ver/site-packages anyway.

As such: either ignore the message or add a rpmlintrc to suppress it (and I'm rather sure that entering Factory will not be stopped by that later on).

But I agree: the packaging policy needs an update here, stating when and why the python-prefix needs to be in a package; otherwise we'll never have a clear consensus to give out to our packagers to get this resolved.

@Pavol: if I remember right you were largely involved in most of the packaging policies, maybe you can shed some light on this as well?

Dominique

I think an rpmlintrc is best as I can also make a comment about why it's there. Regards Dave P | | -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 06/18/2010 12:01 PM, Marcus Meissner wrote:

On Fri, Jun 18, 2010 at 10:04:41AM +0200, Dave Plater wrote:

...

...

But I agree: the packaging policy needs an update here, stating when and why the python-prefix needs to be in a package; otherwise we'll never have a clear consensus to give out to our packagers to get this resolved.

@Pavol: if I remember right you were largely involved in most of the packaging policies, maybe you can shed some light on this as well?

Dominique

I think an rpmlintrc is best as I can also make a comment about why it's there.

No No No.

if its just a warning, either fix the package or leave the warning in.

Too much rpmlintrc hurt.

Ciao, Marcus

Advice taken. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org