Re: Re: solution for those depending on PEAR packages with non-PEAR

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. This worked already the last 15 years in opensource software development. It's a common practice to do this bundling if NEEDED, in most cases it's not, but sometimes it is, like when the application depends heavily on that library, and the library is changing a lot like API breakages, then it can be useful to bundle it. Or if the upstream author of the library is not cooperative, or is acting very slowly. Please _do not_ provide any patch-handling in a package management software (/usr/bin/pear). Thanks -- Regards, Mirco 'meebey' Bauer PGP-Key: http://keyserver.noreply.org/pks/lookup?op=get&search=0xEEF946C8 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d s-:+ a-- C++ UL++++$ P L++$>+++$ E- W+++$ N o? K- w++>! O---- M- V? PS PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y? ------END GEEK CODE BLOCK------

Attachment: [application/pgp-signature] This is a digitally signed message part signature.asc