Re: status on picard-tools and issue with libsnappy-java
Le 8/13/12 1:35 PM, Andreas Tille a écrit :
> On Mon, Aug 13, 2012 at 08:07:22PM +0900, Charles Plessy wrote:
>> For libsnappy-java, since it still only has 10 Popcon users, of which I already
>> contribute 2 or 3 points because I develop on multiple machines, we can also do
>> something very "dark side", that is a) downgrade libsnappy-java to 1.0.3 using
>> an epoch, and b) request its removal from Wheezy.
> Its dirty but probably solves the problem in a way that causes the least
> work for us currently. However, I think the popcon count is anyway
> "alarming" enough to assume that we might leave some unhappy users
I'd rather like avoiding a removal.
I'd still prefer packaging a v1.0.3 ( with an epoch) that conflicts
with the current version and a picard-tools that recomments 1.0.3.
If 1.0.3 is not present, it does not matter, picard-tools will work. It
is only "mandatory" for picard-tools building.
>> Note to the other readers: this is really something that usually should not be
>> done. Please forget what you read !
> What did you wrote? Probably need to start reading from top because I
> forgot what was written there. ;-)
>> What do you think ?
> I have a slight preference for Oliviers suggestion and I'd be fine with
> waiting once he is back from holidays. We should keep the dirtier
> method (which was in some mail I need to reread because I forgot) in
> mind if something might cause any problem.
> There might be a third way that also qualifies as dirty solution: As I
> said we could inject LoadSnappy.java as patch and by doing so build the
> package successfully. Then we could *Conflict* picard-tools with
> libsnappy-java to make sure that the class is not found at execution
> time. Could you please exlpain again the advantage of having libsnappy
> for the picard-tools user?
> Kind regards
> gpg key id: 4096R/326D8438 (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438