[PD-dev] deb packages discussion

dmotd inaudible at simplesuperlativ.es
Tue Sep 22 12:12:23 CEST 2009


nice to see a lot of discussion, i can't fathom 
replying to the various threads happening 
here as i am fairly time poor at present, but i 
thought i'd take the time to make my position as 
clear as possible before getting mixed up with any 
particular argument. apologies if i become a bit 
verbose!

so, lets just take a quick step back -

debian is one single operating system and
packagers for debian can package pd in any way
they wish, sliced, diced, recombined or with a
flight simulator if they choose.

pd-extended could be assembled from parts as a
meta package, there's no issue there.

as long as a user of extended on windows or osx
can run their patch on a debian linux machine
without a diminished experience then there should
be no concern for how their version of extended
was assembled.

so this i am all quite happy with!!

but, while the debian way is good for debian, its 
not the same fit for other environments. a user of 
windows doesn't have the same packaging comforts 
as apt-get and feels far more comfortable with an 
assembled installer, sure they could pick and 
choose their parts, but part of the luxury of 
extended is that its mostly all there and from a 
new user perspective this makes it instantly more 
rewarding than a blank canvas with hundreds of 
unknown installable modules.

but there are alternatives to extended.. planet 
ccrma has been a very reliable package set for a 
number of fedora users and i think this may be on 
a similar tangent to what both anderson and tim 
are proposing here for debian. similarly pure:dyne 
maintains their own version of pd, but in a 
different manner - also worth looking at.

i too agree that a monalythic build system does 
not make sense for long term maintainability, and 
makes pd as an environment far less configurable 
for specific needs - but i still support the 
existence and sustained efforts at packaging 
pd-extended, it just can be assembled better with 
greater modularity (making it a template of 
sorts).

what is important is that pd and its externals 
build evenly for the multitude of different 
platforms and that there is no bias towards 
individual operating systems. this is a balance 
that hans has very carefully respected with 
extended, iohannes and co have maintained with gem 
and what miller generously started with pd.

and that's why i am working on reshaping the 
existing build environments to become more 
modular, in which there is a method for building 
each lib as a self contained vessel from its own 
directory (tarball or whatever), while allowing 
each lib to be tightly woven into any number of 
custom builders seamlessly.

the inspiration is not mine and the initial 
groundwork was conducted by IOhannes and hans as a 
proof of concept demonstrated in the ext13 library 
(as well as motex and apple). i have been working 
on methods to make this template more managable 
for complex projects, better integrated into 
modular build *systems* and simpler to engage with 
for both newbies and devs alike. it should also 
make creating custom maintainer scripts much 
simpler.

i am not so concerned with any particular 
packaging system, what i am interested in is a 
simple configurable modular system that builds and 
installs source into a given tree / jail or 
whatever you like to call it, in the same manner 
for each target platform, while also providing 
useful tools for gathering information and tests 
for libs, objects and reference material.

what package maintainers do to integrate their 
needs is entirely up to them, but should be done 
in such a way without touching the behaviour of 
the overall build mechanism, rather simply
extending its functionality through modular 
scripts and wrappers.

debian is one world view, its one i have used 
before, but not one i subscribe to currently 
myself, so please excuse my naivety when it comes 
to the inner workings and build semantics of a 
debian machine. i am however, cautious when it 
comes to mixing ideologies (or stubborn attitudes) 
of a certain 'way' with a system which should 
ideally provide simple navigation for a number of 
'ways'. as long as there is respect for different 
methods then the debian gods can also get their 
way ;)

anyhow, i have been making steady progress over 
the previous weeks and i should have a snapshot 
ready shortly for perusal. if you want to talk 
directly about my work on the buildsystem i 
frequent the #dataflow channel of irc.freenode.org 
along with hans and a number of others. sorry i 
can't be more explicit with what i am assembling 
but it's still a bit of shifting target. i also 
have a dayjob - so this work is divided 
around scattered freetime so i hope it doesn't 
seem painfully slow, there'll be something to 
digest and potentially hack about with soon, so 
patience is appreciated. my methods may be rubish 
too, but i have given it a fair bit of 
consideration, and so too have others, so in this 
case i think improvement is a better solution than
straight up reinvention (but its always exciting 
to be proved wrong!!).

thanks!
dmotd





More information about the Pd-dev mailing list