ch as 1.09998.
I think it would be better to use a separate soversion, starting
with 0 and only incrementing it, when the API/ABI is broken.
Best regards,
Andreas
1: https://github.com/rbrito/pkg-libvidstab
>From 8019116661556a800166ee84947f8808feef3086 Mon Sep 17 00:00:00 2001
From: Andreas C
Hi Rogério,
On 05.04.2015 06:30, Rogério Brito wrote:
> It would be super nice to have ffmpeg compiled with libvidstab in Debian.
Yes, that would be nice to have indeed. ;)
> Please, see bug #709193 [0] for a RFP bug. I may consider co-maintaining it,
> if you want (I'm just so full of packages
Hi,
On 26.11.2014 23:48, Jonas Smedegaard wrote:
Quoting Andreas Cadhalpun (2014-11-26 22:53:57)
On 23.11.2014 20:03, Jonas Smedegaard wrote:
As I understand this particular case, Debian doesn't violate the
license direc. It would only be violated if a Debian user distributed
one of the G
Hi Jonas,
On 23.11.2014 20:03, Jonas Smedegaard wrote:
If you stumble across a license violation in Debian - be it in
experimental, backports, freeze or oldstable - file a very severe
bugreport about it. Yes, so severe that the issue *must* be dealt with,
and if by no othere means then by remov
Hi,
On 23.11.2014 03:09, Reinhard Tartler wrote:
On Sat, Nov 22, 2014 at 6:51 AM, Andreas Cadhalpun
wrote:
That's a nice idea, but just as the shlibs.local method, it doesn't work in
all cases. See my previous example of libkfilemetadata4, which would still
have the problem, becau
Hi,
On 22.11.2014 13:48, Felipe Sateler wrote:
On Sat, Nov 22, 2014 at 8:51 AM, Andreas Cadhalpun
wrote:
That's a nice idea, but just as the shlibs.local method, it doesn't work in
all cases. See my previous example of libkfilemetadata4, which would still
have the problem, becau
Hi,
On 22.11.2014 10:11, Fabian Greffrath wrote:
I have two more ideas regarding this issue:
1) We have two library packages that conflict with each other. Why don't
we have two -dev packages that conflict with each other, then?
I suggest to introduce a new libavcodec-extra-dev package that de
Hi,
On 20.11.2014 21:00, Jonas Smedegaard wrote:
Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
On 19.11.2014 13:09, Jonas Smedegaard wrote:
Possibly we can simplify even further:
* Have package libavcodec-extra-NN provide virtual libavcodec-extra
(i.e. non-versioned name of
Hi,
On 19.11.2014 13:09, Jonas Smedegaard wrote:
Possibly we can simplify even further:
* Have package libavcodec-extra-NN provide virtual libavcodec-extra
(i.e. non-versioned name of itself)
* Let GPLv2 packages conflict against libavcodec-extra (i.e. not
replace but complement
Hi,
On 19.11.2014 15:25, Reinhard Tartler wrote:
On Nov 19, 2014 8:24 AM, "Nicolas George" mailto:geo...@nsup.org>> wrote:
> It is perfectly legal and compatible with the license to USE a GPLv2
> program with a GPLv3 shared library or the other way around. Licenses can
> only control distribu
Hi,
On 19.11.2014 04:02, Reinhard Tartler wrote:
On Tue, Nov 18, 2014 at 5:55 PM, Andreas Cadhalpun
wrote:
Furthermore I don't think it can always work.
For example look at the dependencies of libkfilemetadata4:
* libavformat56, which depends on libavcodec56 | libavcodec-ext
Hi,
On 18.11.2014 01:25, Reinhard Tartler wrote:
On Mon, Nov 17, 2014 at 5:53 PM, Andreas Cadhalpun
wrote:
All of them have an alternative dependency on libavcodec-extra-56, which is
strictly speaking a license violation.
Probably appropriate Conflicts relationships between them and
Hi,
On 13.11.2014 15:12, Fabian Greffrath wrote:
Right, I believe there are many libavcodec-using packages out there that
are licensed under GPLv3 or similar licenses, whereas we forcefully keep
the default library package at GPLv2. Are there any counter-examples?
Several packages using libavc
13 matches
Mail list logo
