On Tue, Jan 21, 2014 at 7:28 PM, Anton Khirnov an...@khirnov.net wrote:
Libavdevice is not really a standalone library, it depends (by
definition) on libavformat internal symbols. As there are no real reason
for it to be a separate library, the best solution for the associated ABI
problems is
On 22/01/14 08:10, Anton Khirnov wrote:
On Wed, 22 Jan 2014 00:42:10 +0100, Luca Barbato lu_z...@gentoo.org wrote:
On 21/01/14 19:28, Anton Khirnov wrote:
Libavdevice is not really a standalone library, it depends (by
definition) on libavformat internal symbols. As there are no real reason
On 2014-01-22 10:56:27 +0100, Luca Barbato wrote:
The only marginal problem is having loads of external libraries pulled
in and that might or might not annoying certain people.
We don't pull most external libraries automatically in. only sdl, zlib
and bzlib and maybe something I missed.
On Wed, Jan 22, 2014 at 4:56 AM, Luca Barbato lu_z...@gentoo.org wrote:
The only marginal problem is having loads of external libraries pulled
in and that might or might not annoying certain people.
who do you mean with certain people? It will annoy all binary
redistributors, because this way,
On Wed, 22 Jan 2014 08:20:19 -0500, Reinhard Tartler siret...@gmail.com wrote:
On Wed, Jan 22, 2014 at 4:56 AM, Luca Barbato lu_z...@gentoo.org wrote:
The only marginal problem is having loads of external libraries pulled
in and that might or might not annoying certain people.
who do you
On Wed, 22 Jan 2014 08:10:40 +0100, Anton Khirnov an...@khirnov.net wrote:
On Wed, 22 Jan 2014 00:42:10 +0100, Luca Barbato lu_z...@gentoo.org wrote:
On 21/01/14 19:28, Anton Khirnov wrote:
Libavdevice is not really a standalone library, it depends (by
definition) on libavformat
The only reason I have implemented this pattern is because of licensing
reasons: gplv2 only applications must not be linked against gplv3 only
libraries.
I am not willing to introduce more libraries to avoid dependencies. The
current situation is already bad enough.
As for the merge itself, I am
On Wed, 22 Jan 2014 08:54:28 -0500, Reinhard Tartler siret...@gmail.com wrote:
The only reason I have implemented this pattern is because of licensing
reasons: gplv2 only applications must not be linked against gplv3 only
libraries.
I am not willing to introduce more libraries to avoid
Libavdevice is not really a standalone library, it depends (by
definition) on libavformat internal symbols. As there are no real reason
for it to be a separate library, the best solution for the associated ABI
problems is to merge it with libavformat.
---
Changelog
Oh god please no please no.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Tue, Jan 21, 2014 at 10:10 PM, Kieran Kunhya kier...@obe.tv wrote:
Oh god please no please no.
+1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 1/21/2014 9:10 PM, Kieran Kunhya wrote:
Oh god please no please no.
ph'nglui mglw'nafh libavdevice hell wgah'nagl fhtagn
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 21/01/14 19:28, Anton Khirnov wrote:
Libavdevice is not really a standalone library, it depends (by
definition) on libavformat internal symbols. As there are no real reason
for it to be a separate library, the best solution for the associated ABI
problems is to merge it with libavformat.
On Wed, 22 Jan 2014 00:42:10 +0100, Luca Barbato lu_z...@gentoo.org wrote:
On 21/01/14 19:28, Anton Khirnov wrote:
Libavdevice is not really a standalone library, it depends (by
definition) on libavformat internal symbols. As there are no real reason
for it to be a separate library, the
14 matches
Mail list logo
