libwebm as shared library
Tobias Hansen
I'm packaging a program that uses libwebm for Debian and I'm wondering
whether it makes sense to distribute libwebm as a shared library in its
own package. Do you plan to keep the API backwards-compatible? Or is
every software using libwebm intended to ship its own libwebm copy?
Kind regards,
Tobias Hansen
Matthew Heaney
We attempt to keep the library backwards-compatible as much as
possible. It is of course intended as a general-purpose webm parser
library, but it also optimized around the particular needs of the webm
components (among other things, incremental parsing of HTTP byte
streams), so we occasionally must change things a bit as we discover
new needs. (For example, this morning a user reported a problem when
attempting to a parse a webm file that had been truncated.)
What we often do here is create a third_party folder in the
application (whatever that application might be), so the application
can link to a specific version of the library. (For example, we
released 1.0.0.20 yesterday. An app can get the version value by
calling mkvparser::GetVersion.) This isolates the app somewhat from
library changes, compared to linking directly to whatever happens to
be in HEAD at the moment the app is built. When it suits the
application writer, he can update his copy of libwebm and make
adjustments as necessary. New libwebm releases are often just pure
bug-fixes, in which case there would be nothing he would need to do
except update his copy.
The git repository is always tagged ("git tag -a ...") when we make a
new release, so you can always refer to it that way too.
-Matt
Tobias Hansen
> On Wed, Mar 16, 2011 at 12:03 PM, Tobias Hansen
> <Tobias...@physik.uni-hamburg.de> wrote:
>
>> I'm packaging a program that uses libwebm for Debian and I'm wondering
>> whether it makes sense to distribute libwebm as a shared library in its own
>> package. Do you plan to keep the API backwards-compatible? Or is every
>> software using libwebm intended to ship its own libwebm copy?
>>
> We attempt to keep the library backwards-compatible as much as
> possible. It is of course intended as a general-purpose webm parser
> library, but it also optimized around the particular needs of the webm
> components (among other things, incremental parsing of HTTP byte
> streams), so we occasionally must change things a bit as we discover
> new needs. (For example, this morning a user reported a problem when
> attempting to a parse a webm file that had been truncated.)
>
Did you have to change the libraries interface because of that?
(Otherwise it would of course have nothing to do with
backwards-compatibility.)
> What we often do here is create a third_party folder in the
> application (whatever that application might be), so the application
> can link to a specific version of the library. (For example, we
> released 1.0.0.20 yesterday. An app can get the version value by
> calling mkvparser::GetVersion.) This isolates the app somewhat from
> library changes, compared to linking directly to whatever happens to
> be in HEAD at the moment the app is built. When it suits the
> application writer, he can update his copy of libwebm and make
> adjustments as necessary. New libwebm releases are often just pure
> bug-fixes, in which case there would be nothing he would need to do
> except update his copy.
>
Ok, but Debian and other Linux distributions try to avoid code
duplication, unless the code is intended to be used in this way (for
example because the developer doesn't want to worry about
backwards-compatibility). [1]
I'm not sure yet, do you endorse usage as a shared labrary? If you do,
would you add an option to build libwebm as a shared labrary to the
makefiles? Then I would create a Debian package of the library.
[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
Kind regards,
Tobias Hansen
Matthew Heaney
<Tobias...@physik.uni-hamburg.de> wrote:
>
> Did you have to change the libraries interface because of that? (Otherwise
> it would of course have nothing to do with backwards-compatibility.)
Not necessarily. For example, the change I just made changes only the
semantics of the API (in a favorable way), not the syntax of any
calls.
> I'm not sure yet, do you endorse usage as a shared labrary? If you do, would
> you add an option to build libwebm as a shared labrary to the makefiles?
> Then I would create a Debian package of the library.
I have no opinion one way or the other, but if you think libwebm would
be useful as a shared library, then let's just make it so.
You can either make the change yourself and I'll approve it (we use
Gerrit for this purpose), or you can send me a patch file of the
changes and I'll merge it in myself.
Instructions here for uploading changes to the repository:
http://www.webmproject.org/code/contribute/submitting-patches/
More general info here:
http://www.webmproject.org/code/
Gerrit info here:
http://review.webmproject.org/Documentation/user-upload.html
-Matt
Tobias Hansen
>> I'm not sure yet, do you endorse usage as a shared labrary? If you do, would
>> you add an option to build libwebm as a shared labrary to the makefiles?
>> Then I would create a Debian package of the library.
>>
> I have no opinion one way or the other, but if you think libwebm would
> be useful as a shared library, then let's just make it so.
>
In this case I'll first see if the Debian people consider it necessary
and get back to you in case they do. Thanks for now.
Kind regards,
Tobias Hansen