Well,
Too many messages for this morning... later responses will come... i think we are getting closer to a team work.. :D
Just to point out something interesting.. the notes below has a good workflow strategy to deal with packaging on the source. The main idea is create branches with the files from each distribution... i am not experienced with that workflow, but looking it quickly it seems to be a good way to manage our work... maybe one branch for debian/ other for rpm and for gentoo... so the master branch would be always clean! :D
http://www.eyrie.org/~eagle/notes/debian/
ah, a strange problem happened here yesterday. I tried to checkout the svn repository at sourceforge and it couldn't finish... svn occupied all my RAM and swap memory and my computer started do kill process running out of memory.. (which has 4GB). I stopped and run svn up with no success... Any ideas?
bye, global
On Wed, Sep 23, 2009 at 7:42 AM, dmotd inaudible@simplesuperlativ.eswrote:
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 :)
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev