openshot.developers team mailing list archive
-
openshot.developers team
-
Mailing list archive
-
Message #00314
Re: Openshot 0.9.34 Debian/Ubuntu package is now in the PPA
On Wed, 2009-09-16 at 22:08 -0500, Jonathan Thomas wrote:
> TJ,
> I tested out the newest version in the PPA (in VirtualBox-Jaunty 64
> bit) and it worked great! Thanks again for getting this stuff into a
> PPA!
>
> Sorry if this is a dumb question, but how hard would it be to have
> other versions of Ubuntu supported in the PPA? Such as 8.04, 8.10,
> and the new 9.10?
To support 8.04 Hardy and 8.10 Intrepid it would require the latest
ffmpeg and MLT and all their dependencies to be built for those older
platforms, if the versions in the archives are too old.
The problem with back-porting like that is that usually the dependencies
have dependencies have dependencies, and the current versions of the
primary packages relied upon require recent versions of their
dependencies, which don't exist in the original archives.
So you end up having to back-port a large number of other packages (I
once had a package that would have required more than 20 other packages
be updated/back-ported).
This hides the fact that often the packages you want to back-port (say
from Karmic to Hardy) contain debian/patches or debian/rules constructs
that are not compatible with the older distro release, or have changed
APIs that would break other applications that rely upon them even if
they worked for OpenShot.
= Karmic =
I have been working on the Karmic version. It depends on the underlying
binaries and originally I had an up-to-date ffmpeg-unstripped package on
both Jaunty and Karmic working fine.
== FFmpeg blues ==
However, the new Debian ffmpeg imported into Ubuntu Karmic has broken
things in a major way, and I've got to find some time to get it sorted
out. I'm still not sure of the exact sequence of events but it went
something like this.
The key issue is, the naming and content of the ffmpeg packages has
changed over the last year, and changed back again, due to legal
concerns over 'free' and 'non-free' (Debian definitions) codecs.
Originally all ffmpeg codecs were in binary "ffmpeg" and "lib*" packages
that are built from the "ffmpeg" source.
Then, Debian decided to split the package due to the legal concerns into
a 'stripped' ("ffmpeg") and -unstripped ("ffmpeg-unstripped") versions -
the latter available only from the non-main pocket (universe on Ubuntu).
This removed key codecs such as MPEG-4 and FAAC and others and caused a
lot of pain since these codecs were only available in the new
-unstripped binary packages whilst most applications that depended on
ffmpeg still depended on the 'regular' named binary packages that had
those codecs stripped.
So then it was decided to rename the package with potentially non-free
codecs as "-extra" - I'm not clear what benefit this had.
I'm very confused at this point, but as far as I can tell, Ubuntu took a
different view over potential patent issues for the these codecs and
decided to put them back into 'main', but instead of including the
"-extra" (aka "-unstripped") binary packages which would create a
dependency conflict hell, from what I can figure out they simply swapped
the names so "-extra" is the 'stripped' version with codecs missing and
the 'regular' binaries have the codecs!
I may have details here wrong but trying to follow the twists and turns
got so confusing I gave up on it a couple of weeks ago and have been
resisting being drawn back into it since :)
I will be tackling this so that by the time of the Karmic beta OpenShot
can run on Karmic.
It looks likely I'll have to maintain two different MLT packages, one
for Jaunty as it is now, and an alternative one for Karmic. It is MLT
that declares the ffmpeg dependencies.
Karmic has a relatively up to date ffmpeg (July) and may well be
refreshed again if we're lucky, in which case it isn't so vital to
maintain an alternate ffmpeg and MLT. That said, I shall need to anyway
since we'll always be needing the latest improvements especially around
MPEG-TS and AVCHD/H.264 as well as the seek issues.
> I just tallied up the downloads per Ubuntu version, and it looks
> like Jaunty is by far our most popular target platform. But there
> have been over 1000 downloads for non-Jaunty versions also.
The Ubuntu development process is Long Term Release (LTS) followed by a
couple of development releases then another LTS. Hardy was the last LTS
and Karmic is the next. Intrepid and Jaunty are development releases.
This means the archives will not be supported for as long as the LTSs,
and updates aren't seen as important.
I'd suggest that once Karmic is released at the end of October OpenShot
recommend that as the 'base' version. The basic reason is simply the
pain and effort of trying to maintain up-to-date versions of the
dependency packages outside of the main distro.
FFmpeg in Karmic should be suitable for most purposes (aside from the
known AVCHD/MPEG-TS seek issues). MLT still needs to be maintained
outside of Karmic since we need the "python-mlt" SWIG bindings.
Except for security fixes, I'd suggest once Karmic is released, we leave
the OpenShot versions of FFmpeg and MLT alone.
We can then focus on Karmic+1: getting "python-mlt" added to the main
MLT package and ensuring FFmpeg keeps up with upstream so OpenShot gets
the benefit of fixes without needing to maintain separate packages.
If "python-mlt" is accepted we can then push to get OpenShot included in
the "universe" pocket in time for Karmic+1 release.
>
> Last question: Are PPAs CPU architecture independent? Will the
> current Januty PPA work on both 64 bit and 32 bit CPUs?
Because OpenShot is scripts not binaries it doesn't have
architecture-specific packages, just an "_all" that works for all
architectures.
It depends on recent versions of some graphics libraries, and of course
MLT that in turn depends on recent versions of FFmpeg - both have
compiled binaries - so if those aren't available for other architectures
OpenShot won't be installable either.
References