Hi, Do .so files installed in %{python_sitearch} MUST be filtered? I see one reference at https://fedoraproject.org/wiki/Common_Rpmlint_issues#private-shared-object-p... but the filtering policy is not added to Python packaging guidelines. Also, why rpmlint complains it as warning and not an error? e.g. one case I see is pyorbit.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/ORBit.so ORBit.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator.
Regards, Parag.
On Sun, Sep 26, 2010 at 07:33:40PM +0530, Parag N(पराग़) wrote:
Hi, Do .so files installed in %{python_sitearch} MUST be filtered? I see one reference at https://fedoraproject.org/wiki/Common_Rpmlint_issues#private-shared-object-p... but the filtering policy is not added to Python packaging guidelines. Also, why rpmlint complains it as warning and not an error? e.g. one case I see is pyorbit.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/ORBit.so ORBit.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator.
Thanks for bringing this up!
I was looking at this for a package a few weeks ago and found that this guideline was in the normal packaging guidelines:
https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFilter...
but I did not remember approving it. It was moved into the main packaging Guidelines when spot made the changes that moved the backlog of approved guidelines from the Todo list into the main guidelines. I found where we had discussed it the first time: https://fedoraproject.org/wiki/Packaging:Minutes/20090602#t12:39
but after that meeting we (FPC) didn't meet for a while due to different people being on vacation and thus not being able to make quorum. Meeting logs are not present during this time so I can't tell if I was on vacation and it was approved or if it got moved into the main Guidelines by mistake.
This guideline would impact what we do for filtering private python provides as it specifies:
""" MUST: Packages must not provide RPM dependency information when that information is not global in nature, [...] MUST: When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used [...] """
-Toshio
Hi,
2010/9/26 Toshio Kuratomi a.badger@gmail.com:
On Sun, Sep 26, 2010 at 07:33:40PM +0530, Parag N(पराग़) wrote:
Hi, Do .so files installed in %{python_sitearch} MUST be filtered? I see one reference at https://fedoraproject.org/wiki/Common_Rpmlint_issues#private-shared-object-p... but the filtering policy is not added to Python packaging guidelines. Also, why rpmlint complains it as warning and not an error? e.g. one case I see is pyorbit.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/ORBit.so ORBit.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator.
Thanks for bringing this up!
I was looking at this for a package a few weeks ago and found that this guideline was in the normal packaging guidelines:
https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFilter...
but I did not remember approving it. It was moved into the main packaging Guidelines when spot made the changes that moved the backlog of approved guidelines from the Todo list into the main guidelines. I found where we had discussed it the first time: https://fedoraproject.org/wiki/Packaging:Minutes/20090602#t12:39
but after that meeting we (FPC) didn't meet for a while due to different people being on vacation and thus not being able to make quorum. Meeting logs are not present during this time so I can't tell if I was on vacation and it was approved or if it got moved into the main Guidelines by mistake.
This guideline would impact what we do for filtering private python provides as it specifies:
""" MUST: Packages must not provide RPM dependency information when that information is not global in nature, [...] MUST: When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used [...] """
Thanks for this information. Will this be discussed in next FPC meeting and added to python packaging guidelines page?
Regards, Parag.
On Sun, Sep 26, 2010 at 07:33:40PM +0530, Parag N(पराग़) wrote:
Do .so files installed in %{python_sitearch} MUST be filtered? I see one reference at https://fedoraproject.org/wiki/Common_Rpmlint_issues#private-shared-object-p... but the filtering policy is not added to Python packaging guidelines. Also, why rpmlint complains it as warning and not an error? e.g. one case I see is pyorbit.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/ORBit.so ORBit.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator.
I talked with spot and then went through old meeting logs and found that this was approved. on July 28, 2009. I've added the logs from that meeting here: https://fedoraproject.org/wiki/Packaging:Minutes/20090728
Here's the Guidelines page that resulted from that meeting: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
Note that although we would like to filter out all of the unnecessary stuff, there are some packages where we shouldn't because of rpm limitations: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Us...
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I've linked that page to the Packaging:Python page and also to the rpmlint page.
I also found that the Packaging:Perl page was recommending a different recipe so I've put in a ticket to change those to the new macros: https://fedorahosted.org/fpc/ticket/16
-Toshio
Hi Toshio,
2010/9/28 Toshio Kuratomi a.badger@gmail.com:
On Sun, Sep 26, 2010 at 07:33:40PM +0530, Parag N(पराग़) wrote:
Do .so files installed in %{python_sitearch} MUST be filtered? I see one reference at https://fedoraproject.org/wiki/Common_Rpmlint_issues#private-shared-object-p... but the filtering policy is not added to Python packaging guidelines. Also, why rpmlint complains it as warning and not an error? e.g. one case I see is pyorbit.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/ORBit.so ORBit.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator.
I talked with spot and then went through old meeting logs and found that this was approved. on July 28, 2009. I've added the logs from that meeting here: https://fedoraproject.org/wiki/Packaging:Minutes/20090728
Here's the Guidelines page that resulted from that meeting: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
Note that although we would like to filter out all of the unnecessary stuff, there are some packages where we shouldn't because of rpm limitations: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Us...
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I've linked that page to the Packaging:Python page and also to the rpmlint page.
I also found that the Packaging:Perl page was recommending a different recipe so I've put in a ticket to change those to the new macros: https://fedorahosted.org/fpc/ticket/16
Thanks you for quickly updating and explaining the filtering usage in guidelines page.
Regards, Parag.
On Tuesday 28 September 2010, Toshio Kuratomi wrote:
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I still think that related recipes in Wiki should be constructed so that specfiles containing this stuff continues to work also on distro versions that don't have those macros. For example the above could be written as:
%{?filter_setup: %filter_provides_in %{python_sitearch}/.*.so$ %filter_setup}
On 29/09/10 07:25, Ville Skyttä wrote:
On Tuesday 28 September 2010, Toshio Kuratomi wrote:
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I still think that related recipes in Wiki should be constructed so that specfiles containing this stuff continues to work also on distro versions that don't have those macros. For example the above could be written as:
%{?filter_setup: %filter_provides_in %{python_sitearch}/.*.so$ %filter_setup}
Or it could be encapsulated in a language-specific macro included in the python package, much like what is already done for perl, where the perl module spec files just contain:
%{?perl_default_filter}
Paul.
On Wed, Sep 29, 2010 at 09:29:45AM +0100, Paul Howarth wrote:
On 29/09/10 07:25, Ville Skyttä wrote:
On Tuesday 28 September 2010, Toshio Kuratomi wrote:
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I still think that related recipes in Wiki should be constructed so that specfiles containing this stuff continues to work also on distro versions that don't have those macros. For example the above could be written as:
%{?filter_setup: %filter_provides_in %{python_sitearch}/.*.so$ %filter_setup}
Or it could be encapsulated in a language-specific macro included in the python package, much like what is already done for perl, where the perl module spec files just contain:
%{?perl_default_filter}
I asked this on https://fedorahosted.org/fpc/ticket/16#comment:2 but maybe you can answer here instead:
What package is defining that macro and from what Fedora version? Do you know if RHEL5/6 has it as well?
-Toshio
On Wed, 29 Sep 2010, Toshio Kuratomi wrote:
On Wed, Sep 29, 2010 at 09:29:45AM +0100, Paul Howarth wrote:
On 29/09/10 07:25, Ville Skyttä wrote:
On Tuesday 28 September 2010, Toshio Kuratomi wrote:
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I still think that related recipes in Wiki should be constructed so that specfiles containing this stuff continues to work also on distro versions that don't have those macros. For example the above could be written as:
%{?filter_setup: %filter_provides_in %{python_sitearch}/.*.so$ %filter_setup}
Or it could be encapsulated in a language-specific macro included in the python package, much like what is already done for perl, where the perl module spec files just contain:
%{?perl_default_filter}
I asked this on https://fedorahosted.org/fpc/ticket/16#comment:2 but maybe you can answer here instead:
What package is defining that macro and from what Fedora version? Do you know if RHEL5/6 has it as well?
RHEL 6 should have it as redhat-rpm-config is pretty much just inherited from Fedora. RHEL 5, no.
But... if people are starting to mass-disable the internal dependency generator just to avoid provides from python/perl/etc private modules, I think the better fix would be changing rpmbuild to handle that particular case (extension module for an otherwise known interpreted language) automatically.
- Panu -
On Wed, 29 Sep 2010 13:33:44 -0400 Toshio Kuratomi a.badger@gmail.com wrote:
On Wed, Sep 29, 2010 at 09:29:45AM +0100, Paul Howarth wrote:
On 29/09/10 07:25, Ville Skyttä wrote:
On Tuesday 28 September 2010, Toshio Kuratomi wrote:
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I still think that related recipes in Wiki should be constructed so that specfiles containing this stuff continues to work also on distro versions that don't have those macros. For example the above could be written as:
%{?filter_setup: %filter_provides_in %{python_sitearch}/.*.so$ %filter_setup}
Or it could be encapsulated in a language-specific macro included in the python package, much like what is already done for perl, where the perl module spec files just contain:
%{?perl_default_filter}
I asked this on https://fedorahosted.org/fpc/ticket/16#comment:2 but maybe you can answer here instead:
What package is defining that macro and from what Fedora version? Do you know if RHEL5/6 has it as well?
It's in perl-devel (/etc/rpm/macros.perl), and went in at perl 4:5.10.0-79, so it's in an updated Fedora 11 but not one just installed from media.
It's in RHEL-6 but not earlier RHELs.
Paul.
On Wed, Sep 29, 2010 at 09:25:43AM +0300, Ville Skyttä wrote:
On Tuesday 28 September 2010, Toshio Kuratomi wrote:
The way to filter this out is probably something like this: # we don't want to provide private python extension libs %filter_provides_in %{python_sitearch}/.*.so$ # actually set up the filtering %filter_setup
I still think that related recipes in Wiki should be constructed so that specfiles containing this stuff continues to work also on distro versions that don't have those macros. For example the above could be written as:
%{?filter_setup: %filter_provides_in %{python_sitearch}/.*.so$ %filter_setup}
Examples on the Packaging page updated with this conditional and a small explanation added about why we conditionalize this. Please let me know if there's further clarification that you think would be good.
-Toshio
On Sun, 26 Sep 2010 13:01:54 -0400 Toshio Kuratomi wrote:
On Sun, Sep 26, 2010 at 07:33:40PM +0530, Parag N(पराग़) wrote:
Hi, Do .so files installed in %{python_sitearch} MUST be filtered? I see one reference at https://fedoraproject.org/wiki/Common_Rpmlint_issues#private-shared-object-p... but the filtering policy is not added to Python packaging guidelines. Also, why rpmlint complains it as warning and not an error? e.g. one case I see is pyorbit.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/ORBit.so ORBit.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator.
Thanks for bringing this up!
I was looking at this for a package a few weeks ago and found that this guideline was in the normal packaging guidelines:
https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFilter...
but I did not remember approving it. It was moved into the main packaging Guidelines when spot made the changes that moved the backlog of approved guidelines from the Todo list into the main guidelines. I found where we had discussed it the first time: https://fedoraproject.org/wiki/Packaging:Minutes/20090602#t12:39
but after that meeting we (FPC) didn't meet for a while due to different people being on vacation and thus not being able to make quorum. Meeting logs are not present during this time so I can't tell if I was on vacation and it was approved or if it got moved into the main Guidelines by mistake.
This guideline would impact what we do for filtering private python provides as it specifies:
""" MUST: Packages must not provide RPM dependency information when that information is not global in nature, [...] MUST: When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used [...] """
Would it be possible to first make the macros.filtering linked from the wiki page from above available by default? http://fedorapeople.org/~cweyl/macros.filtering
Then it would be far easier to filter unwanted provides out, than currently possible.
Thanks, Thomas
On 27/09/10 09:57, Thomas Spura wrote:
On Sun, 26 Sep 2010 13:01:54 -0400 Toshio Kuratomi wrote:
On Sun, Sep 26, 2010 at 07:33:40PM +0530, Parag N(पराग़) wrote:
Hi, Do .so files installed in %{python_sitearch} MUST be filtered? I see one reference at https://fedoraproject.org/wiki/Common_Rpmlint_issues#private-shared-object-p... but the filtering policy is not added to Python packaging guidelines. Also, why rpmlint complains it as warning and not an error? e.g. one case I see is pyorbit.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/ORBit.so ORBit.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator.
Thanks for bringing this up!
I was looking at this for a package a few weeks ago and found that this guideline was in the normal packaging guidelines:
https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFilter...
but I did not remember approving it. It was moved into the main packaging Guidelines when spot made the changes that moved the backlog of approved guidelines from the Todo list into the main guidelines. I found where we had discussed it the first time: https://fedoraproject.org/wiki/Packaging:Minutes/20090602#t12:39
but after that meeting we (FPC) didn't meet for a while due to different people being on vacation and thus not being able to make quorum. Meeting logs are not present during this time so I can't tell if I was on vacation and it was approved or if it got moved into the main Guidelines by mistake.
This guideline would impact what we do for filtering private python provides as it specifies:
""" MUST: Packages must not provide RPM dependency information when that information is not global in nature, [...] MUST: When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used [...] """
Would it be possible to first make the macros.filtering linked from the wiki page from above available by default? http://fedorapeople.org/~cweyl/macros.filtering
Then it would be far easier to filter unwanted provides out, than currently possible.
They have been available by default (included in redhat-rpm-config) since Fedora 10.
Paul.
packaging@lists.fedoraproject.org
-
Panu Matilainen -
Parag Nemade -
Paul Howarth -
Thomas Spura -
Toshio Kuratomi -
Ville Skyttä