Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1013007 - sudo bundles zlib
Summary: sudo bundles zlib
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Kopeček
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: DuplicSysLibsTracker
TreeView+ depends on / blocked
 
Reported: 2013-09-27 15:03 UTC by Alec Leamas
Modified: 2015-07-30 00:40 UTC (History)
4 users (show)

Fixed In Version: sudo-1.8.14p1-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-30 00:40:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
irc log (deleted)
2013-09-27 15:05 UTC, Alec Leamas
no flags Details

Description Alec Leamas 2013-09-27 15:03:36 UTC
Description of problem:

Package contains a bundled copy of zlib which is not removed during %prep.
This violates https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries

Comment 1 Alec Leamas 2013-09-27 15:05:50 UTC
Created attachment 803988 [details]
irc log

Comment 2 Daniel Kopeček 2013-09-30 14:56:25 UTC
Hello,

(In reply to Alec Leamas from comment #0)
> Description of problem:
> 
> Package contains a bundled copy of zlib which is not removed during %prep.
> This violates
> https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries

does it really violate what is stated in the referenced document? I don't think so:

  * It is not necessary to remove bundled libraries from the source tarball unless there is a legal reason to do so

  * Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to delete the bundled source code during %prep. Packages in this exception case MUST document this situation in a specfile comment, and verify that the functionality is properly conditionalized with each update. 

sudo doesn't use the bundled copy of zlib. Anyway, a comment regarding this is missing, so I'll add it in the next update. Do you agree with this resolution or do you see a strong reason to remove the sources before the %build phase?

Thanks,
Dan K.

Comment 3 Alec Leamas 2013-09-30 15:40:39 UTC
Hi!

I think you are missing this one in the very beginning of the reference:
---
Bundled libraries (and/or their source code) must be explicitly deleted during %prep. Build scripts may need to be patched to deal with this situation. Whenever possible, the patching should be done in a way to conditionalize use of the bundled libraries, so that it can be sent upstream for consideration. 
---

OTOH, we are not talking about removing zlib from the srpm. And since you don't use that code at all, it isn't a subset used to provide functionality not available upstream. 

Ergo: remove in %prep (which is a simple oneliner).

Comment 4 Daniel Kopeček 2013-09-30 18:01:38 UTC
(In reply to Alec Leamas from comment #3)
> Hi!
> 
> I think you are missing this one in the very beginning of the reference:
> ---
> Bundled libraries (and/or their source code) must be explicitly deleted
> during %prep. Build scripts may need to be patched to deal with this
> situation. Whenever possible, the patching should be done in a way to
> conditionalize use of the bundled libraries, so that it can be sent upstream
> for consideration. 
> ---

The build scripts don't need patching. They already count with this situation. They detect whether there's devel support for zlib on the system and use that if possible. If it's not, then the bundled copy is used. And that's the situation the exception covers, isn't it? My point is that it's absolutely useless to delete anything in this case. What's the benefit of removing sources only before the build? If we shipped a tarball without them instead, that would safe some negligible space, but that's not the case we are talking about.

Comment 5 Alec Leamas 2013-09-30 18:46:47 UTC
> (In reply to Daniel Kopeček from comment #4)
> (In reply to Alec Leamas from comment #3)
> > Hi!
> > 
> > I think you are missing this one in the very beginning of the reference:
> > ---
> > Bundled libraries (and/or their source code) must be explicitly deleted
> > during %prep. Build scripts may need to be patched to deal with this
> > situation. Whenever possible, the patching should be done in a way to
> > conditionalize use of the bundled libraries, so that it can be sent upstream
> > for consideration. 
> > ---
> 
> The build scripts don't need patching. They already count with this
> situation. They detect whether there's devel support for zlib on the system
> and use that if possible. If it's not, then the bundled copy is used. And
> that's the situation the exception covers, isn't it? 

No it's not. The exception is for using the bundled lib in a situation where you can't use the system lib (the system zlib in this case). Since you are using the system lib, the exception is not applicable.

> My point is that it's
> absolutely useless to delete anything in this case. What's the benefit of
> removing sources only before the build? If we shipped a tarball without them
> instead, that would safe some negligible space, but that's not the case we
> are talking about.

What you do here is actually to question the GL. If you want to do that, the proper procedure is to raise the issue with FPC who maintains them. However, before doing that it's probably best to raise the issue on the mailing list. I have some thoughts why they are like this, but there are certainly more knowledged people on the list.

That said, this bug must be handled according to the existing GL IMHO.

Comment 6 Alec Leamas 2014-04-04 08:34:17 UTC
See also discussion in bug #1077812, where Ville SKyttä clarifies the situation.

Comment 7 Jaroslav Reznik 2015-03-03 16:55:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 8 Fedora Update System 2015-07-21 11:37:25 UTC
sudo-1.8.14p1-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/sudo-1.8.14p1-1.fc22

Comment 9 Fedora Update System 2015-07-23 08:54:08 UTC
Package sudo-1.8.14p1-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sudo-1.8.14p1-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11942/sudo-1.8.14p1-1.fc22
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2015-07-30 00:40:47 UTC
sudo-1.8.14p1-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.