[PD-dev] deb packages discussion

[Tim Jones]

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.