Hi Max. I need your help in figuring out the correct strategy for upgrading gettext.
There are two issues, which I will keep separate so as not to confuse things. As I've mentioned before, the major version number in libintl.dylib has changed in recent versions of gettext, so we need a new gettext2 package. Constructing gettext2-shlibs and gettext2-dev is no problem, and these will obviously coexist with existing packages. (I remind you that "gettext" contains the shlibs, for backwards compatibility, and is an Essential package, while "gettext-dev" is not an Essential package and can be swapped in and out with gettext2-dev.) The problem arises with the executables, like /sw/bin/gettext. At the moment, they are in "gettext-bin" which is an Essential package. I'm having a hard time finding an upgrade strategy when this package is Essential. If it weren't Essential, I could just create "gettext2" to contain v.2 of the executables, and swap it back and forth with "gettext-bin". But I can't do that with an Essential package. However, I am a bit nervous about removing the "Essential" tag from gettext-bin. There might be some packages that depend on this, right? Not too likely, but possible. I suppose one thing I could do is to add "BuildDepends: gettext-bin" to every package which currently says "BuildDepends: gettext-dev". But would that be enough? The other option I thought of was to continue keeping the gettext executables in a package called "gettext-bin", which would now become a splitoff of "gettext2" and get a later version number. The newer versions of gettext-bin would depend on gettext2-shlibs not gettext. The problem with this approach is that iw would be difficult to "go back" to earlier versions. (It's particularly hard for apt-get users, since I don't believe apt-get will recognize the older versions.) This would also mean that we have to make gettext2-shlibs into an Essential package immediately, since the latest version of the Essential package gettext-bin would depend on it. Your thoughts on this would be most welcome. I have packages for gettext2 ready to go, except for getting the depedency issues sorted out. I also have a package for the latest texinfo ready to go, which depends on gettext2-shlibs. Oh yes, I mentioned that there are two issues. The second issue is that the upstream maintainers of gettext are now recommending that packagers separate gettext into "gettext-runtime" and "gettext-tools". I'm planning to do this with gettext2 unless you think it's a bad idea. It means six total packages for fink (gettext2, gettext2-shlibs, gettext2-dev, gettext2-tools, gettext2-tools-shlibs, gettext2-tools-dev) but a smaller installation requirement for bootstrapping and for most users. Some of the executables which are currently in "gettext-bin" will end up in "gettext2-tools" rather than "gettext2", so this affects the earlier discussion of dependencies as well. Best, Dave P.S. cc-ing to fink-devel in case other people have input as well. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
