Re: Re: solution for those depending on PEAR packages

Mirco Bauer wrote:

On Sat, 2005-04-23 at 08:13 -0400, Greg Beaver wrote:

But having official support for forks, patched version, or anything in this direction is not something I like to see in the PEAR installer.

Noted. Others who feel the same way, please respond as well.

Doing...

Greg

(note: this is from the general software development view) When an application depends on a library by someone else, and the application has problems, bugs whatever because of that library, he would contact the library author (often called upstream) to get the library fixed in whatever way. If the author of the application can not wait for a new release of the library, because the author is slowly or maybe even not very cooperative, then the normal solution would be to bundle the library (in the directory of the application, this will not cause ANY conflict), and apply the changes which are needed. Next, when the author of the library now provides a new version which contains the code change (regardless if bug fix or new feature), then the library can be unbundled, means the application uses now again the original library, or it stays bundled but is re-synced. When the author of the application decides to leave it bundled, because he expects further code changes he may need, he can _easily_ track the differences between his bundled library and the original library with the program called "diff". So when the bundled library contains code which will be never included in the original library (like new features which the upstream author doesn't like/want/whatever), then the author of the application can easily create an patch file (diff) of original library vs bundled library (this would include all changes which are done in the bundled library), and apply this patch file to the new version of the original library, and take this one as the new bundled library. This way of syncing, is often just _one command_. Thus bundling is not a big overhead for the author of the application.

so i physically need to add code to my package for a quick fix and then remove that again later where actually the code that needed to be changed was outside of that package. so now i have made this change bigger than it really needed to be (a little addition to the package.xml). so what i will end up doing instead is packaging a new package, publish it on my channel and will have to tell my users to sort of a conflict instead of accepting a patched version which tells the user why this patched version is necessary. so likely what i will end up having to do is talk to each of my clients, which is fine but very unscalable. eitherway not having the ability to do temporary patched versions as dependencies results in people having to publish hacked up versions on their channels (maybe pulling them later etc) resulting in alot of messing around with packages in channels when all you wanted was a quick fix. by that time i will rather *bundle* (is that a euphemism for forking or what?) all packages i depend on right away. then users will only have to worry about conflicts when i setup the system. this means i have to keep updating my forked aeh bundled code all the time, but so it goes. regards, Lukas