[packman] [RFC] Main Dependency Portability was: Re: ffmpeg update to version 2.0

[Marguerite Su]

Hi, Manfred,

On Mon, Jul 29, 2013 at 12:48 AM, Manfred Tremmel
<manfred at links2linux.de> wrote:
>> we should document/maintain a page or develop a policy about:
>>
>> How to port some basic functions from ffmpeg 0.7 series -> 1.0 series
>> and ffmpeg 1.0 series -> 2.0 series, like avcodec_encode_video ->
>> avcodec_encode_video2 or CodecID -> AVCodecID, which are very easy to
>> port (you don't have to be a coder at all, Google will help you do
>> most of the works if you find a similar patch).
>
> Sounds like a good idea, but I'm not sure if we can handle doing the
> upstream work, too.
>

Actually, we've already been doing this for years...eg: ffms, we port
it to 1.0; libextractor, I port it to 2.0 today...actually many
upstream projects just wait for the upstreamed work from distribution
packagers to keep it update...

And FFmpeg actually maintains a good depreciated page:

http://ffmpeg.org/doxygen/trunk/deprecated.html

and their mailing list even provides examples, eg:

http://mplayerhq.hu/pipermail/ffmpeg-devel/2012-August/129832.html

We just need to provide human-readable examples (make upstream
examples more stupid):

eg: CodecID is _replaced_ by AVCodecID, packagers just need to add AV prefix.

or

eg: avcodec_encode_video is _replaced_ by avcodec_encode_video2:

old function: blabla

new function: avcodec_encode_video2(c, &pkt, picture, &got_output)

and explain the parameters in _plain_ language. (every coder can do
so...explaining a function)

I'm not a programmer, but I made a lot of packages. Because the logic
behind patch is human readable...just like word puzzle. You don't have
to understand the whole project or even patch it _right_, you just
need to make it build. We're not making a distribution, we're just a
user community. So all the users are our native testers. Bugzilla is
welcome, or join us and get your hands dirty, :-)

>> Same thing can also apply to gstreamer-0_10 to gstreamer-1_0
>>
>> Here's the simple reason:
>>
>> If upstream ffmpeg has been 2.0 now but a package is still using 0.7,
>> we can consider it as a drop taget or a dead project.
>
> It's easy, if it is a standalone software, but what's about
> libs/programms used by other software?

Such libs/programs are still standalone.

In programming there's a saying called "isolation", which means you
have to keep your implementation hidden from the ABI/APIs you provide.
Downstream just need the ABI/APIs, they don't need your
implementation.

That's the fundamental idea of Unix or modular programming...

In a human readable language: update from ffmpeg 1.0 -> ffmpeg 2.0
shouldn't affect a package that have a dependency which further
depends ffmpeg. Just like a gimp plugin doesn't even care whether gimp
is compiled using gtk+ 2.22 or gtk+ 2.24, it just needs gimp-devel and
everything should be okay.

If that's not the case:

* that dependency is not for Unix at all...not our target
* it's a _very_ dirty project that shouldn't be used on a daily basis.

Greetings

Marguerite