FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 09-27-2010, 03:47 AM
Parag N(पराग़)
 
Default private-shared-object-provides in python packages

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-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 [...]
> """
>
>
Thanks for this information. Will this be discussed in next FPC
meeting and added to python packaging guidelines page?

Regards,
Parag.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 09-27-2010, 10:10 AM
Paul Howarth
 
Default private-shared-object-provides in python packages

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-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.

They have been available by default (included in redhat-rpm-config)
since Fedora 10.

Paul.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 09-29-2010, 12:18 AM
Parag N(पराग़)
 
Default private-shared-object-provides in python packages

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-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

Thanks you for quickly updating and explaining the filtering usage in
guidelines page.

Regards,
Parag.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 09-29-2010, 06:25 AM
Ville Skytt
 
Default private-shared-object-provides in python packages

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

Thread Tools




All times are GMT. The time now is 06:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org