When people use Pd-extended 0.42.5, they expect that certain libraries will be there, and they will be a certain version. For example Pd-extended 0.42.5 includes Gem 0.92.3. So you can say "my patch works with Pd-extended 0.42.5" and it'll work with any installation of Pd-extended 0.42.5
If Pd-extended 0.42.5 also looks at /usr/lib/pd, then someone could install Gem 0.93 there and Pd-extended would use it. Let's say Gem 0.93 introduces an obscure bug which breaks your patch. Then someone who has installed Pd-extended 0.42.5 can no longer be sure that the patch will always work with Pd-extended 0.42.5. So my plan going forward with Pd-extended is to get all the libs in Debian, and then actually based Pd-extended on all platforms on which pd libraries are in Debian. Windows, Mac OS X, etc. will be built the same: as one big package. This is the best way I can see then to guarantee compatability across platforms. .hc On Wed, 2010-09-15 at 21:22 +0200, Roman Haefeli wrote: > 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@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 > > > > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list