[PD-dev] deb packages discussion

[dmotd]

tim,

yup with you all the way here, i've been chatting 
a bit to mescalinum about his work with gentoo 
too, and i'm pretty sure we're all after the same 
goal.

cheers,
dmotd

Tim Jones wrote:
> > 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 :)