Re: Re: dependencies andapplications

On 21 Aug 2003 at 17:35, Jan Schneider wrote: > Zitat von Stefan Neufeind <stefan@neufeind.net>: > > > On 21 Aug 2003 at 17:05, Jan Schneider wrote: > > > > > Zitat von Lukas Smith <smith@backendmedia.com>: > > > > > > > The PEAR Installer for applications installs the pear packages > > > > that are needed into a seperate directory. > > > > > > I still don't see a need for this. If one writes an application > > > that depends on a certain version of a package, either the > > > application is badly written or the package maintainer is so > > > unreliable in keeping the api bc that you shouldn't use his > > > package at all. > > I know you are starting to get confused ;-), but please don't mix up > things. Trying to ... really. Trying hard, already! But can't digest the people anymore :-)) > > In some cases you can't avoid breaking BC. Surely this has to be > > done with a major version change (demanded by the pear-rules). But > > what if you or a customer running on your server have an application > > requiring the old API and one requiring the new one? With the > > approach of being able to have multiple major versions installed at > > the same time this problem is fixed for all time ... and I really > > think it's the best solution to this - really! > > This case is handled with my approach. But Lukas talked about > something different. Well, at least I think so, but maybe I'm confused > now too. :-) > > He proposed that dependant packages that an application might have and > that get installed by the pear installer, will be installed in a > different directory only for that application. And that is a bad idea > and unnecessary IMHO. Yes, agreed totally. You shouldn't demand to have a per-application- repository since this would make centralized updates MUCH harder, breaks (most | all) byte-code-caches and also consumes much diskspace. I am strongly (!) against this since I believe having a per-application-installation is against everything in our pear- concept. If you have one application with this version-problem you can surely solve it that way. But then you could also simply fix the app to the new API :-) But as stated in a previous email: When you do virtual hosting for maybe ~100 or more virtual hosts on one machine you can't ask everybody if you "may please upgrade to MDB 2 because it's needed by app XY". And you can't upgrade and if somebody cries switch back or things like that. And you can't say "If it breaks anything in your apps then simply copy the needed version to your private include path and don't use the libraries from the global pear- installation". If it were one package (e.g. MDB) and few virtual hosts that's all no problem. But with the situation I'm thinking of / dealing with this not an acceptable way to got at all. > If the packages' maintainers are not completly without a clue there > is no need to not a rely on that applications won't break if you > upgrade to a new minor version. You're my hero, in this case ... that's what I tried explaining - but you put it just in a few less words than I did in a previous email :- ))) Stefan