On Fri, Jun 04, 2010 at 04:57:40PM -0400, Alexandre Quessy wrote:
Hello Jonas,So I have set up a Debian sid box. That will help. :)
Good!
2010/6/4 Jonas Smedegaard <d...@jones.dk>:On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:Done. I will have to add your license to the copyright of some of the Debian packaging.What I do is maintain packaging licensing in debian/rules. And I (ideally, when not too lazy) do not add licensing info of others but instead request them to add it themselves. ;-)Oops! I added your name to debian/copyright. Please edit it or remove it if it's not the way you like.
No problem. I only tried to aim at a best practice. :-)
It does seem, however, from a quick glance, that some parts of the project is not arch-limited. It might be a good idea to split packaging to provide most possible to all archs.That would be nice, but it's probably going to be difficult. The jack-info, dc-ctl and midistream utilities could be packages separately, and should be useful for the multimedia-loving masses. Since scenic relies on milhouse, they could be packaged together. Again, I am a close-to-beginner in packaging, so I am not sure where to start, especially that the current build process is unified and using a single autotools configure.ac script. It would imply splitting it upstream, no?Packaging typically goes like this: 1. Prepare 2. configure 3. build 4. install 5. reinstall into package area 6. tune packaging Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.So splitting into multiple packages is (more or less) a simple matter of adding more binary packages in debian/control and hinting in debian/*.install which autotools-installed parts each of them should contain.Ok, so in this case, let's say we brake it into 3 packages:* scenic (contains the Python app, the documentation, the glade data, and the icon, etc.)* scenic-utils (dc-ctl, firereset, jack-info and milhouse executables. Man pages and some shared libraries) * midistream (python app and man page) The easiest way would be to create 3 *.install files. The quick benefit to this, is that we will have a few packages that are architecture-independant, namely the two Python-only binary packages: scenic and midistream. That totally makes sense.
Yes, that seems sensible (from reading it alone - I must admit that I have not yet tried compiling the project and looking at the results).
I am looking for an example of doing this... (which uses cdbs and the autotools, if possible) Got any?
sugar-0.88That one also demonstrates quite well IMO how a large amount of package dependencies are easier to track indirectly declared in debian/rules, as they they can be grouped and comments added as needed.
- Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
