Created attachment 803988 [details]
irc log

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.

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

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

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

See also discussion in bug #1077812, where Ville SKyttä clarifies the situation.

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

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

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

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.