Bug 1268333
| Summary: | Upgrade liblzf to 3.8 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Pisar <ppisar> |
| Component: | liblzf | Assignee: | Steve Traylen <steve.traylen> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | steve.traylen |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://cvs.schmorp.de/liblzf/Changes?revision=1.59&view=markup | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Petr Pisar
2015-10-02 14:35:49 UTC
http://cvs.schmorp.de/liblzf/Changes?view=markup so it's unreleased, not clear what to do. I would say don't update perl-Compress-LZF unless there is need to? I think you could persuade liblzf upstream to release 3.8 as a standalone library. Obviously he thinks the code mature enough if he could release Perl binding for it. I exchanged few emails with upstream and he does not want to release liblzf because he does not see a reason for it. Moreover he states, that he does not like unbundling liblzf from Perl Compress-LZF:
On Sat, Jan 23, 2016 at 06:57:21PM +0100, Marc Lehmann wrote:
> On Fri, Jan 22, 2016 at 10:56:19AM +0100, Petr Pisar <ppisar> wrote:
> > > Well, I am not in the habit of making releases for no reason. Speciifcally,
> > > there should be a reason to make a release, the absence of a reason to the
> > > contrary doesn't qualify - so, is there anything in the 3.8 release that you
> > > need in some way?
> > >
> > The lzf_compress_best().
> >
> > > If you could explain you reasons I could try top bump the priority, but
> > > again, since this is volunteer work, I can make no guarantees, and cetrainly
> > > wouldn't want to prepare a release for no reason.
> > >
> > The reason is sharing liblzf code among Compress-LZF and other programs that
> > use liblzf. We link Compress::LZF against liblzf to have only one libzf code
> > in the system.
>
> Since that requires larger modifications (as the standalone C lib is not
> binary compatible), I think you are on your own - I don't think fedora
> should ship considerably different and incompatible versions of some
> library than other distributions. Certainly I wouldn't want to *help* with
> that, but of course, it's free software, and you are free to do what you
> want.
Just reviewed this, I don't there is any change. We can pull a release from CVS I guess. Reviewed no change. No change. |