[PD] Pd-extended 0.42.5 release candidate 6 released!
Roman Haefeli
reduzent at gmail.com
Wed Sep 15 21:22:32 CEST 2010
On Wed, 2010-09-15 at 09:13 -0400, Hans-Christoph Steiner wrote:
> Its never possible to fix all known bugs in a given release.
Yeah, I understand. I was assuming that it is only about adding another
entry to /usr/lib/pd-extended/default.pdextended . If it is really that
simple I don't see a reason not to do it just now. If not, I understand
your hesitation.
> The
> combination of the big single package that Pd-extended currently is
> with the single packages for each library in /usr/lib/pd makes for a
> very complicated situation.
Probably I am overseeing something, but how can it harm to load
something from /usr/lib/pd after all other default pathes have been
checked? I believe, that is what now users have to do anyway when they
want to use something like gridflow or [readanysf~] in pdextended:
adding /usr/lib/pd/extra to the pathes.
> So its much less work to just wait for
> went Pd-extended is also packaged as one-lib-per-package, then this
> will be solved with very little work.
Yo, I didn't mean to open another can of worms, of course. But I am not
sure, if I can see a can at all here.
Roman
> On Sep 15, 2010, at 3:11 AM, Roman Haefeli wrote:
>
> > On Tue, 2010-09-14 at 19:45 -0400, Hans-Christoph Steiner wrote:
> >> Pd-extended 0.42.5 is done, so it'll stay as is.
> >
> > Ok. Since you called, I thought I'd report what I think needs to be
> > fixed.
> >
> >> Pd-extended 0.43
> >> will work with /usr/lib/pd. For 0.43, only libs that require Pd-
> >> extended will be installed into /usr/lib/pdextended.
> >
> > Sounds good, though I still don't understand why not fixing it right
> > now.
> >
> > Roman
> >
> >
> >> On Sep 14, 2010, at 5:59 PM, Roman Haefeli wrote:
> >>
> >>> On Tue, 2010-09-14 at 16:38 -0400, Hans-Christoph Steiner wrote:
> >>>> That means that it installs all its libs into /usr/lib/
> >>>> pdextended
> >>>
> >>> Yeah, makes sense also to me.
> >>>
> >>>> and ignores /usr/lib/pd.
> >>>
> >>> Why?
> >>>
> >>> You seem to ignore the fact, that there are pd-libs around in the
> >>> wild,
> >>> that are _not_ part of Pd-extended and thus would be very useful
> >>> to be
> >>> used together with Pd-extended, but unfortunately do not work
> >>> out-of-the-box, because pdextended doesn't look in /usr/lib/pd.
> >>>
> >>> I'd propose to add /usr/lib/pd as the last path in the search order,
> >>> so
> >>> that it wouldn't interfere with everything installed
> >>> in /usr/lib/pd-extended. I don't see how this would hurt with the
> >>> current behaviour. When having pd-motex installed and using some
> >>> objects
> >>> from motex, still /usr/lib/pd-extended would be used (instead
> >>> of /usr/lib/pd, where pd-motex installs to). Nevertheless, [wiimote]
> >>> from pd-wiimote which installs to /usr/lib/pd would be found.
> >>>
> >>> Please enlighten me, if I am overseeing something and my proposal
> >>> would
> >>> actually break something.
> >>>
> >>> Roman
> >>>
> >>>
> >>>
> >>>> The next step for Debian packaging for Pd-extended is having each
> >>>> lib
> >>>> in its own package, and then making a 'pdextended' package which
> >>>> provides 'pd' and is just the core. That will then look in /usr/
> >>>> lib/pd.
> >
> >
> >
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ----------------------------------------------------------------------------
>
> News is what people want to keep hidden and everything else is
> publicity. - Bill Moyers
>
>
More information about the Pd-list
mailing list