Advice about upstream using old libraries

[gil]

Built Apache Flume 1.5.2
Disabled module (not available buildeps or NON free):
flume-ng-dist
flume-dataset-sink
flume-ng-elasticsearch-sink
(i use F20 build feps for these modules arent available)
flume-ng-hbase-sink
flume-ng-morphline-solr-sink
use activemq-core >= 5.7.0
flume-twitter-source

flume-jms-source

disable jetty 6.1.26 support
use guava 11.x, i disabled some feature for now

Open/update these bug:
irclib https://bugzilla.redhat.com/show_bug.cgi?id=1178861
mapdb https://bugzilla.redhat.com/show_bug.cgi?id=976049
regards
- gil

Il 05/01/2015 15:28, Tim St Clair ha scritto:
> Out of curiosity, have you tried setting up containers and running via atomic.
>
> You may not get official channels, but you could create recipes for Atomic and add to Docker Hub.
>
> Just a thought...
>
> Cheers,
> Tim
>
> ----- Original Message -----
>> From: "Javi Roman" <jroman.espinar at gmail.com>
>> To: "Fedora Big Data SIG" <bigdata at lists.fedoraproject.org>
>> Sent: Monday, January 5, 2015 12:42:19 AM
>> Subject: Re: Advice about upstream using old libraries
>>
>> Many thanks for your answers.
>>
>> I'm going to try patch Flume with Fedora Thrift version, I'm agree
>> that is probably the best way, I guess people at upstream is not
>> working on it. This is a blocking issue in order to include Flume in
>> Fedora package repositories.
>> --
>> Javi Roman
>> es.linkedin.com/in/javiroman
>>
>>
>> On Sun, Jan 4, 2015 at 7:20 PM, Mikolaj Izdebski <mizdebsk at redhat.com> wrote:
>>> On 01/04/2015 09:33 AM, Javi Roman wrote:
>>>> The Apache Flume upstream code is using a old library (Apache Thrift
>>>> v0.8.0) however Fedora packages are using Apache Thrift 0.9.1 since
>>>> log time ago [2]. The problem is the v0.9.1 version breaks the
>>>> upstream building [3], and nobody is working in the issue right now.
>>>>
>>>> The question is about the steps or procedure from a Fedora packager
>>>> point of view:
>>>>
>>>> 1. Try to fix the break code by myself, or working with the upstream
>>>> people in order to fix it (probably complex task).
>>>> 2. Try to package the older version of the library and make it
>>>> available in the fedora packages repository.
>>> There is no universal aswer here, the right choice depends on number of
>>> factors, including:
>>> - is the old version still maintained by upstream?
>>> - is it difficult to port to newer version?
>>> - would upstream eventually accept the patch?
>>> - are there other packages that require older version?
>>> - what impact has using different version than upstream? (estimate)
>>> - ...
>>>
>>> Usually it's best to start with 1st option and fall back to 2nd one if
>>> there are some problems. My algorithm in most cases is:
>>> - check if upstream already tried to update to newer verion
>>> - if not then attempt to prepare the patch yourself
>>> - if it's too hard to prepare patch, fallback to creating compat package
>>> - build and test rpm package with the patch created
>>> - send the patch upstream
>>>
>>> --
>>> Mikolaj Izdebski
>>> Software Engineer, Red Hat
>>> IRC: mizdebsk
>>> _______________________________________________
>>> bigdata mailing list
>>> bigdata at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/bigdata
>> _______________________________________________
>> bigdata mailing list
>> bigdata at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/bigdata
>>