[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