Well,<br><br>Too many messages for this morning... later responses will come... i think we are getting closer to a team work.. :D<br><br>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<br>
<br><a href="http://www.eyrie.org/~eagle/notes/debian/">http://www.eyrie.org/~eagle/notes/debian/</a><br><br>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?<br>
<br><br>bye, global<br><br><div class="gmail_quote">On Wed, Sep 23, 2009 at 7:42 AM, dmotd <span dir="ltr"><<a href="mailto:inaudible@simplesuperlativ.es">inaudible@simplesuperlativ.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
tim,<br>
<br>
yup with you all the way here, i've been chatting<br>
a bit to mescalinum about his work with gentoo<br>
too, and i'm pretty sure we're all after the same<br>
goal.<br>
<br>
cheers,<br>
<font color="#888888">dmotd<br>
</font><div><div></div><div class="h5"><br>
Tim Jones wrote:<br>
> > pd-extended could be assembled from parts as a<br>
> > meta package, there's no issue there.<br>
><br>
> I guess my point is that, if I download the pd-extended tarball, it is<br>
> not easy at all to assemble it as a series of parts, not as easy and<br>
> efficient as it could be. At the very least, I think there needs to be<br>
> some housekeeping done.<br>
><br>
> > as long as a user of extended on windows or osx<br>
> > can run their patch on a debian linux machine<br>
> > without a diminished experience then there should<br>
> > be no concern for how their version of extended<br>
> > was assembled.<br>
><br>
> Correct! I think Anderson and I are complaining strictly as packagers.<br>
><br>
> > but, while the debian way is good for debian, its<br>
> > not the same fit for other environments. a user of<br>
> > windows doesn't have the same packaging comforts<br>
> > as apt-get and feels far more comfortable with an<br>
> > assembled installer, sure they could pick and<br>
> > choose their parts, but part of the luxury of<br>
> > extended is that its mostly all there and from a<br>
> > new user perspective this makes it instantly more<br>
> > rewarding than a blank canvas with hundreds of<br>
> > unknown installable modules.<br>
><br>
> All I'm asking for is increased modularity, which is more than just<br>
> the debian way. Though admittedly I have no idea how Windows<br>
> installers are built, but I don't think it would be difficult to have<br>
> a check box or something that says "Install Everything! (Recommended,<br>
> seriously. Default.)" What I'm really seeking is improvement on<br>
> modularity for the _build_, not necessarily the package.<br>
><br>
> > but there are alternatives to extended.. planet<br>
> > ccrma has been a very reliable package set for a<br>
> > number of fedora users and i think this may be on<br>
> > a similar tangent to what both anderson and tim<br>
> > are proposing here for debian. similarly pure:dyne<br>
> > maintains their own version of pd, but in a<br>
> > different manner - also worth looking at.<br>
><br>
> I'll have a look at these. (I'm working on Gentoo :)<br>
><br>
> > i too agree that a monalythic build system does<br>
> > not make sense for long term maintainability, and<br>
> > makes pd as an environment far less configurable<br>
> > for specific needs - but i still support the<br>
> > existence and sustained efforts at packaging<br>
> > pd-extended, it just can be assembled better with<br>
> > greater modularity (making it a template of<br>
> > sorts).<br>
><br>
> Yesss. This is what I want. I just really think pd-extended should be<br>
> assembled, virtually, in package repositories rather than in<br>
> sourceforge (perhaps with the exception of windows and mac?)<br>
><br>
> > what is important is that pd and its externals<br>
> > build evenly for the multitude of different<br>
> > platforms and that there is no bias towards<br>
> > individual operating systems. this is a balance<br>
> > that hans has very carefully respected with<br>
> > extended, iohannes and co have maintained with gem<br>
> > and what miller generously started with pd.<br>
><br>
> Agreed. I can't conceive that what I'm advocating would cause problems<br>
> for Windows and Mac package creation, but maybe I am biased just from<br>
> ignorance.<br>
><br>
> > and that's why i am working on reshaping the<br>
> > existing build environments to become more<br>
> > modular, in which there is a method for building<br>
> > each lib as a self contained vessel from its own<br>
> > directory (tarball or whatever), while allowing<br>
> > each lib to be tightly woven into any number of<br>
> > custom builders seamlessly.<br>
><br>
> Sounds great.<br>
><br>
> > i am not so concerned with any particular<br>
> > packaging system, what i am interested in is a<br>
> > simple configurable modular system that builds and<br>
> > installs source into a given tree / jail or<br>
> > whatever you like to call it, in the same manner<br>
> > for each target platform, while also providing<br>
> > useful tools for gathering information and tests<br>
> > for libs, objects and reference material.<br>
><br>
> Now we're talking.<br>
><br>
> > what package maintainers do to integrate their<br>
> > needs is entirely up to them, but should be done<br>
> > in such a way without touching the behaviour of<br>
> > the overall build mechanism, rather simply<br>
> > extending its functionality through modular<br>
> > scripts and wrappers.<br>
><br>
> Yes. And I have really been picking apart the current build mechanism<br>
> in the Gentoo ebuild I have been working on, which is bad, but<br>
> necessary to make it really modular. I would be happy if I did not<br>
> need to do this.<br>
><br>
> > anyhow, i have been making steady progress over<br>
> > the previous weeks and i should have a snapshot<br>
> > ready shortly for perusal. if you want to talk<br>
> > directly about my work on the buildsystem i<br>
> > frequent the #dataflow channel of <a href="http://irc.freenode.org" target="_blank">irc.freenode.org</a><br>
> > along with hans and a number of others. sorry i<br>
> > can't be more explicit with what i am assembling<br>
> > but it's still a bit of shifting target. i also<br>
> > have a dayjob - so this work is divided<br>
> > around scattered freetime so i hope it doesn't<br>
> > seem painfully slow, there'll be something to<br>
> > digest and potentially hack about with soon, so<br>
> > patience is appreciated. my methods may be rubish<br>
> > too, but i have given it a fair bit of<br>
> > consideration, and so too have others, so in this<br>
> > case i think improvement is a better solution than<br>
> > straight up reinvention (but its always exciting<br>
> > to be proved wrong!!).<br>
><br>
> Awesome. Maybe I'll just shut up until I see what you've got going :)<br>
<br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@iem.at">Pd-dev@iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/pd-dev" target="_blank">http://lists.puredata.info/listinfo/pd-dev</a><br>
</div></div></blockquote></div><br>