OK, there are a few general points about naming. (I'm not sure exactly how they apply to this case.)
Once you've named a shlibs package, you should stick with that name until the next time there is an upgrade which is not backward-compatible. Even after changing to a new non-backward-compatible version, you need to keep the "old" shlibs package around indefinitely (for the sake of anything that is linked to it). So, for example, if mysql needs an update to mysql12-shlibs, then we still need a mysql-shlibs package (built with the old version) to stay around. The naming "policy" should never be interpreted to mean that a name of an existing package should be changed to conform to policy. When you introduce a new package, or a binary-incompatible new version of a package, then please do use the fooN-shlibs convention, but don't make this change just for the sake of conformity to policy. Remember that the Shlibs field in a -shlibs package amounts to a promise by the maintainer that the libraries listed in Shlibs will always be available in the package whose name is mentioned in the Shlibs field. As I say, I'm not sure how all of this applies to the current case. Since you've now introduced mysql12-shlibs as well as mysql-shlibs, it seems to me that you'll need a new package which simply creates "mysql-shlibs" using the old version of the source. -- Dave ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
