[PD-dev] deb packages discussion

[Tim Jones]

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

I guess my point is that, if I download the pd-extended tarball, it is
not easy at all to assemble it as a series of parts, not as easy and
efficient as it could be. At the very least, I think there needs to be
some housekeeping done.

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

Correct! I think Anderson and I are complaining strictly as packagers.

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

All I'm asking for is increased modularity, which is more than just
the debian way. Though admittedly I have no idea how Windows
installers are built, but I don't think it would be difficult to have
a check box or something that says "Install Everything! (Recommended,
seriously. Default.)" What I'm really seeking is improvement on
modularity for the _build_, not necessarily the package.

> 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'll have a look at these. (I'm working on Gentoo :)

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

Yesss. This is what I want. I just really think pd-extended should be
assembled, virtually, in package repositories rather than in
sourceforge (perhaps with the exception of windows and mac?)

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

Agreed. I can't conceive that what I'm advocating would cause problems
for Windows and Mac package creation, but maybe I am biased just from
ignorance.

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

Sounds great.

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

Now we're talking.

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

Yes. And I have really been picking apart the current build mechanism
in the Gentoo ebuild I have been working on, which is bad, but
necessary to make it really modular. I would be happy if I did not
need to do this.

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

Awesome. Maybe I'll just shut up until I see what you've got going :)