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 upgradingIndeed. 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.
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.
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.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?
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.
Fine :-)
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 thatYou mean they can be compiled separately? I.e. you are not talking about splitoffs, but gettext-tools really would be a 100% independent package?
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.
OK.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.
Max
------------------------------------------------------- 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
