Hi Hans,<br><br><div class="gmail_quote">On Mon, Sep 21, 2009 at 11:58 AM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@at.or.at">hans@at.or.at</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;">
<div style=""><div><br></div><div>Hey Anderson,</div><div><br></div><div>Its good timing for bringing these up, Günter has stopped maintaining his official Debian packages, so they are officially orphaned right now. Anyone here a Debian Developer? I am starting the process of becoming a Debian Developer (and I'll be helping to run DebCof 2010 in NYC next summer). We could start a Pd group for packaging all this stuff.</div>
<div><br></div></div></blockquote><div><br>This is why I got here... many friends who are working with Pd from a long time told me some problems on installing pd-extended on other plattaforms. And I thought I can help on this... I tried to use the build-farm with no success... it is a huge script and the build files of some externals are so complicated that I could not compile them... I am studying a lot about autotools, compiler, linker stuff and debian packaging to solve those problems...<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div>I think that the 'puredata' and pure:dyne packages would be the best place to start, then they just need to be tailored to be more Debian-proper (i.e. moving all non-libs out of /usr/lib/pd, etc.) and work with the 'pd' virtual package. I</div>
<div><br></div></div></blockquote><div><br>This is what I am trying to do right now... As you know, I am a new user of Pd but an old user and C and package developer... now I am working with Pd and the problems with pd-extended on AMD64 lead me to think about rewriting or rethinking the way of packaging... <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div>Plus dmotd, IOhannes, me and others are working on rewriting build system so it should be easier to package the libraries individually.</div>
<div><br></div></div></blockquote><div><br>The big problem I see here is: you and others made a very big build system with incredible worth.. my proposal maybe will break many things that you already did, as the build farm will change to build so many small deb packages for many distributions and archs.<br>
<br>The work of doing this big changes worth? That is the question we might ask ourselves. Looking beyond the cave I really think YES. Some years ago, when developing Sacix distribution, I had to make a similar decision. I decided to change my way of building packages from a monolitic to a "distributed" way.. well, I spent 6 months of intense work, too many bugs, broke dependencies, etc. I got a little bit crazy with all those problems and packages, but now I can breath and spend more time on the beach. :D<br>
<br>Maybe the best way is to work in parallel, maintain the pd-extended and create a separate repo with all deb packages and this new experience ... this new repo will need I huge work, I know, but my experience told me that worth. <br>
<br>I have about 40 packages in sacix distribution to maintain. How this works to build all of them? I have a simple build script that enters in the directory of the package, run debuild command and go to another one.. I can skip some of them if it is broken just adding the package to a shell var. Today, the only work is to upgrade the package if a new version of the software is released (like firefox). Of course many packages are configuration only, so this almost does not change. <br>
<br>I am gonna lunch.. after that I will try to answer dmotd...<br><br>bye, global<br></div></div><br>