openshot.developers team mailing list archive

[TJ <ubuntu@xxxxxxxxxxx>]

On Tue, 2009-08-25 at 22:07 -0500, Jonathan Thomas wrote:
> I looked into Python distutils and python-support when I was first
> researching how to build some .deb packages.  I was quickly defeated
> by those tools, and choose to create the .debs using more traditional
> ways... such as "$ dpkg -b".  Since OpenShot is a desktop application,
> and not just a Python library, I wonder if the python-support command
> even applies???  Sorry I'm not more help.

It always surprises me how a good night's sleep helps in seeing the
obvious! I re-read the distutils documentation I'd been using for
reference yesterday, and in particular the "Installing Scripts" section:

http://docs.python.org/distutils/setupscript.html#installing-scripts

I had also been looking at how the "phatch" application was packaged
since it uses python-support and launches from /usr/bin/phatch.

The way it is done is to install the python launcher script
in /usr/bin/. It uses the shell "sha-bang" operator:

#!/usr/bin/env python

It does this using distutil's regular setup() call with the 'scripts'
array:

setup(..., scripts = ['bin/phatch'], ...)

Looking at the way things are organised in the openshot repository at
the moment made me think it would make sense to refactor the layout in
several ways based on several articles I've read regarding the
quasi-standard source-code layout in many packages. Please review these
observations in case you think they would be worthwhile being adopted
for consistency:

1. Replace the shell script "openshot" (from install/openshot) with a
pure Python script (relocated  to "bin/openshot" which will be a
slightly modified "./OpenShot.py"). 

2. Create a new 'desktop specs' directory, xdg/

3. Move "install/openshot.desktop" to xdg/

4. Move "windows/glade/icons/openshot_logo.png" to "xdg/openshot.png".
(combined with python-xdg's getIconPath("openshot") call in the source
code).

5. remove the "install/" directory and remaining contents completely.

6. Make current language translations less specific as to country. In
other words, for now, instead of "fr_FR" just "fr" and instead of
"fi_FI" just "fi".
This ensures they will cover many more target locales. If in the future
more translations are added then more specific country-based variations
can be added. (see the phatch package list for an example):

http://packages.ubuntu.com/jaunty/all/phatch/filelist

7. Put profiles/ into a new package "openshot-profiles" and have the
"openshot" package depend on it.

8. Put themes/ into a new package "openshot-themes" and have the
"openshot" package depend on it.

I suggest (7) and (8) since it looks like profiles and themes are
semi-independent of the openshot application. Additional profiles/themes
would then not require a new application package to be published.

I'm checking with Ubuntu-MOTU on this though since it seems to me if the
packages are all created from the same source package, the automated
build daemons would build all the binary packages (including the
application) which would result in all being updated - defeating the
object of logical package splitting in many respects.

These packaging decisions shouldn't affect the main application
development but I want to make you aware of my thinking as I go.

I'm currently refactoring my local source repository based on these
suggestions to test the result. If you like/accept the ideas I can send
the patches to achieve this once I've perfected it.

> And I agree with you that the MLT Python bindings need to be installed
> to the /site-packages, since it is a system-wide library that anyone
> should be able to use with Python.

I've found a good example in the package "python-adns" which uses
python-support to do the 'magic':

http://packages.ubuntu.com/jaunty/all/python-adns/filelist

so I should be able to complete the python-mlt package today.