[PD-dev] externals deb packaging questions

Roman Haefeli reduzierer at yahoo.de
Mon May 17 01:00:12 CEST 2010


Hi all

Some questions arose about how to correctly debianize externals. Is it
correct, that since both 'puredata' and 'pd-extended' provide 'pd', an
external binary package should depend on 'pd'? What happens, if you
install 'pd-foo' and neither of the Pd flavours is installed, which one
would be preferred? Currently, only 'puredata' seems to be part of any
apt repository, so there is no ambiguity now, but what if both are
available?

Then I realized, that recent nightly builds for ubuntu use new layout
and install the included externals to /usr/lib/pd-extended/extra,
opposed to the old-fashioned /usr/lib/pd/extra. How is an externals
package meant to support _both_ flavours? Should it install
to /usr/lib/pd/extra and also create a symlink
in /usr/lib/pd-extended/extra ?

If the goal is to debianize all libdirs from current Pd-extended's
extra, why the separation? If in the future Pd-extended differs from
Pd-vanilla only in that, that it has slightly different features, an
enhanced look and different patches applied, why do both need their own
extra directory? And if all the libdirs are moved out of the pd-extended
packages to their own debs, wouldn't the pd-extended package have to
pull in / be dependent on all those pd-lib packages in order to deserve
its name? But then again, the advantage of having separate extra dirs
for two different Pd flavours is not clear to me. 

Also: If there is a separation, what is the reason for having a 'pd'
meta pacakge then?

On a not-quite-related side note: What is the /etc/init.d/pd-extended
script good for? Or: In what way is it useful to run pd-extended as a
daemon?

Roman






More information about the Pd-dev mailing list