Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

[Jonas Smedegaard]

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 <dr at 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.88

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100605/e0548803/attachment.pgp>