Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Packaging (http://www.linux-archive.org/fedora-packaging/)
-   -   private-shared-object-provides in python packages (http://www.linux-archive.org/fedora-packaging/431902-private-shared-object-provides-python-packages.html)

Parag N(पराग़) 09-26-2010 02:03 PM

private-shared-object-provides in python packages
 
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-provides
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.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Toshio Kuratomi 09-26-2010 05:01 PM

private-shared-object-provides in python packages
 
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-provides
> 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/AutoProvidesAndRequiresFiltering

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Thomas Spura 09-27-2010 08:57 AM

private-shared-object-provides in python packages
 
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-provides
> > 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/AutoProvidesAndRequiresFiltering
>
> 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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Toshio Kuratomi 09-28-2010 05:27 PM

private-shared-object-provides in python packages
 
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-provides
>> 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#Usage

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Toshio Kuratomi 09-29-2010 05:33 PM

private-shared-object-provides in python packages
 
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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Panu Matilainen 09-29-2010 06:33 PM

private-shared-object-provides in python packages
 
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 -
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Toshio Kuratomi 09-29-2010 07:05 PM

private-shared-object-provides in python packages
 
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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Paul Howarth 09-29-2010 07:36 PM

private-shared-object-provides in python packages
 
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.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging


All times are GMT. The time now is 02:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.