[PD-dev] deb packages discussion

Anderson Goulart global at codekab.com
Mon Sep 21 18:48:41 CEST 2009


Hi Hans,

On Mon, Sep 21, 2009 at 11:58 AM, Hans-Christoph Steiner <hans at at.or.at>wrote:

>
> Hey Anderson,
>
> 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.
>
>
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...



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


> Plus dmotd, IOhannes, me and others are working on rewriting build system
> so it should be easier to package the libraries individually.
>
>
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.

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

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.

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.

I am gonna lunch.. after that I will try to answer dmotd...

bye, global
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090921/fbf26e04/attachment.htm>


More information about the Pd-dev mailing list