This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 1013007

Summary: sudo bundles zlib
Product: [Fedora] Fedora Reporter: Alec Leamas <leamas.alec>
Component: sudoAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: dkopecek, kzak, leamas.alec, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sudo-1.8.14p1-1.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-29 20:40:47 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 504493    
Attachments:
Description Flags
irc log none

Description Alec Leamas 2013-09-27 11:03:36 EDT
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 11:05:50 EDT
Created attachment 803988 [details]
irc log
Comment 2 Daniel Kopeček 2013-09-30 10:56:25 EDT
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 11:40:39 EDT
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 14:01:38 EDT
(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 14:46:47 EDT
> (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 04:34:17 EDT
See also discussion in bug #1077812, where Ville SKyttä clarifies the situation.
Comment 7 Jaroslav Reznik 2015-03-03 11:55:31 EST
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 07:37:25 EDT
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 04:54:08 EDT
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-29 20:40:47 EDT
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.