Hello Tim,
On Mon, Sep 21, 2009 at 3:07 PM, Tim Jones tjones01@gmail.com wrote:
I've been tweaking a pd-extended Gentoo ebuild for personal use for the last few weeks. It makes more sense to me to package extensions etc. (maybe just "addons" more generally) separately.
Actually I now wonder, why even have pd-extended? It seems that it may be doing to much of the packagers' work for them. Logically, pd-extended is only a meta-package (right?) and may best be left to packagers to implement, so Anderson can do it the way he wants to, I can do it the way I want to, etc. so as to best accommodate the very different packaging systems across all distributions.
This is what I think.. pd-extended could be only a meta-package.
I understand the motivation for pd-extended is to just fork to a stable version. Is this the only reason? Why not just release stable, numbered versions of each external?
I don't know, but I don't think is the only reason.. when I talked to Hans he told me that pd-extended was created to join in one place a bunch of externals/abstractions... because many PD users were making good patches and pubilshed them on their blogs, own repos, etc. So it was dificult to users (or new users) to find those patches... so, if you need a PD with many patches, just install pd-extended and you will get it! This is a good idea! I love it, but not the way of making this happen... :D
I have not talked to him, but I think the guy that maintains the
pd-overlay has stopped maintaining the pd-extended ebuild but still maintains pd-devel and individual live svn ebuilds of the externals. I was tempted to chop up the pd-extended ebuild in a similar fashion, and number the externals with the pd-extended version, like zexy-0.41.4 but this seems repulsive to have two different "version spaces," if you will.
I may also look at gstreamer for inspiration. They release multiple plugins in three packages according to stability. gst-plugins-good -bad and -ugly.
I really don't think the problem is the version of pd.. as we don't have problems on having different firefox versions depending on your target (stable, testing, unstable)...
Naturally as someone on a non-Debian system, I would not want to see it done the Debian-way on the pd-side. I would want to see something modular and adaptable to any system (which is not unheardof). As I have said, I like Anderson's idea of pd-zexy pd-pidip distributed as separate tarballs, but I would leave it to Anderson to carve out his own puredata-dev from a standard build. (So I guess in the case of the -dev package I would favor the overwhelmingly conventional over the modular solution from pd's side.)
Maybe the subject of the thread is misleading... we can distribute or upstream authors can distribute the original source tarballs as other projects do... than I can build a debian package, you can build a gentoo, others can build for redhat, etc..
And I think this will increase the work, comparable to the actual model.. but we can have more hands now to distribute the work! :D
Modularity is the magic word for me. I find myself deconstructing the
pd-extended autobuild system in my ebuild.
hehee.. this is what I think.. and started to do to my AMD64 computer...
Disclaimer: I have written a few ebuilds for personal use and fixed a few broken ones, but I am otherwise not a terribly experienced writer of ebuilds. I am not a software engineer and have never released my own source package. Nor have I even been a Pd user for long. Maybe, I know nothing.
huahuahaa... you are like me... new user of PD, a good C programmer and junior at debian packaging.. besides that, I am just suggesting the way debian developers think (which is documented at debian policy and package maintainers guide)... I think they are smart enough to tell us that separate things are better than create a monolitic package... I trust on them.. hauha
p.s., OT: why are so many externals' *-help.pd files copied to both $objectsdir and $helpdir?? Why copy the same file to two different places? If absolutely necessary, symlinks would be preferred.
I don't know! :D
Anyone like this idea and can help me to do this work? Or have other suggestions?
bye, global
Sorry I lurk too much and forget I have to reply-to-all to mailing lists on gmail. Looks like my message has been completely in Anderson's response earlier.
I understand the motivation for pd-extended is to just fork to a stable version. Is this the only reason? Why not just release stable, numbered versions of each external?
I don't know, but I don't think is the only reason.. when I talked to Hans he told me that pd-extended was created to join in one place a bunch of externals/abstractions... because many PD users were making good patches and pubilshed them on their blogs, own repos, etc. So it was dificult to users (or new users) to find those patches... so, if you need a PD with many patches, just install pd-extended and you will get it! This is a good idea! I love it, but not the way of making this happen... :D
So again, it sounds like the Pd-devs are trying to do the work that packagers should be doing for their distributions. Very thoughtful of course, and appreciated :) but the responsibility should not be thrust upon them. Debain-based systems could have pd-extended or pd-full meta-packages, Gentoo could have a similar virtual ebuild to pull in all the individual packages, and boom, you get all the Pd there is, to make any patch you can find start working. If each package has it's own build system that works nicely, then a short script could be written to simply call ./configure && make install or ./waf install etc. in each necessary directory, a script which would accommodate even those who do not wish to use a package, and may not wish to untar and build 50-something addons. Maybe this sounds like the build system that is already in place, but if each addon has its own system then the master build script should be much, much simpler. BUT, I wouldn't even waste time writing such a script because users who aren't using packages probably aren't the ones overwhelmed by all the externals anyway, and will be able to figure out which external they need and how to install it manually themselves. I've never seen a source package offer this anyway... if you download the source, you're on your own (but it should work). If you want it easy, get a package.
I really don't think the problem is the version of pd.. as we don't have problems on having different firefox versions depending on your target (stable, testing, unstable)...
I just meant it felt wrong, from the packaging perspective, to try to force the solution we're advocating, which would presumable involve slicing the pd-extended package itself, and assigning the version of pd-extended to each of the externals. This seems bad to be because I think in some rare cases, externals do have their own version numbers.
And I think this will increase the work, comparable to the actual model.. but we can have more hands now to distribute the work! :D
It would take some time to change the system already in place, and might require more individual attention to each external at first (not sure how much most of them are changing in svn), but ultimately yes I think it would take some pressure off the developers and put more pressure on packagers to get Pd out there.
Anyone like this idea and can help me to do this work? Or have other suggestions?
I've not done this kind of thing before, but would be interested in learning how to set up individual autotools (or other) based build systems for each external, and figuring out some system of getting stable, numbered releases of each external, if such a solution is advocated. Such a solution, I predict, would make maintenance easier for both the devs and the packagers. I think something needs to change though. While it works, the pd-extended build system is out of control, from my perspective.
-
Anderson Goulart -
Tim Jones