Re: [Fink-devel] gettext upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David R. Morrison wrote: 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. Another possibility is to append the version to the executables, and use update-alternatives to link them up. - -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ Emacs is a nice operating system, but I prefer UNIX. -- Tom Christiansen -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/MS3DUu+jZtP2Zf4RAjXzAJ9XDo8TqM+hNIXwLO+iJV2xKqRBJgCgkWM7 BAKPaYOKh4d2R+Mev19ZVJ4= =Ia5s -END PGP SIGNATURE- --- 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] gettext upgrade
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/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gettext upgrade
I doubt that we can use update-alternatives in gettext. The problem is, the update-alternatives binary is provided by dpkg, but dpkg depends on gettext and so gettext gets built earlier in the bootstrap... -- Dave --- 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gettext upgrade
Hi Max. 1) You are quite right, the man pages belong in -dev. I'll move them. 2) Yes, gettext-runtime and gettext-tools can be compiled completely separately, although they use the same source (and gettext-runtime has to be done first because gettext-tools links to the libs in the other package). 3) I guess in your mail you are implicitly suggesting a third option: put the binaries into the -dev package. This would keep everything together with the correct headers; on the other hand, it would mean that no package could ever Depend on those binaries, only BuildDepend. Would that be enough? -- Dave --- 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gettext upgrade
Am Mittwoch, 06.08.03 um 18:21 Uhr schrieb David R. Morrison: 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. Indeed. BTW an unrelated question: why are the man pages in the -bin splitoff, not in the -dev splitoff ? man3 is documentation for the developer APi after all. 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 am actually not sure if it's that unlikely. I am not a gettext pro, so somebody else will probably know better; but a quick check reveals that the configure sycripts of many gettext using apps refer to various of the tools in gettext-bin (like msgfmt, xgettext etc.). I am not sure in how far those are only used in maintainer mode, or if they are actually used during normal configure/make runs, too... That is something we need to know definitely. 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? I'd hope it should be enough. Strictly spoken, I am not sure if it's a good idea to have -dev and -bin separated (are there scenarios were one would want/need to use one without the other?) In any case, it'd be vital that the -bin and -dev version match; i.e. if an app builds against gettext2-dev, it should see the gettext2-bin, and if it uses gettext-dev, then gettext-bin. Which presumably would be the case if we specify explicit BuildDepends 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.) Not only that, it would mean that developers would be forced to develop their apps against the new gettext. If somebody for some reasons wishes to develop apps based on the old gettext, they won't be able to do that anymore with Fink, because they can't access the older tools anymore (unless the newer tools are 100% compatible to the old ones. I don't know if that's the case or not, but a simple way to find out the answer to this and my above question would be to contact the gettext developers, I'd think) 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. This should not be rushed. It can be annoying to remove the essential status from a package again, so let's make sure we know we are right. 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. Fine :-) 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. You mean they can be compiled separately? I.e. you are not talking about splitoffs, but gettext-tools really would be a 100% independent package? 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. OK. Max --- This SF.Net email sponsored by: Free
