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. :)


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?


That 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

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to