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. _______________________________________________ Mailing list: https://launchpad.net/~openshot.developers Post to : [email protected] Unsubscribe : https://launchpad.net/~openshot.developers More help : https://help.launchpad.net/ListHelp
