Date: Thu, 30 Mar 1995 02:01:40 -0800 From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) To: me@FreeBSD.org Cc: ports@FreeBSD.org Subject: Re: libXpm.so.4.5 Message-ID: <199503301001.CAA07314@silvia.HIP.Berkeley.EDU> In-Reply-To: <m0ru38P-0005fOC@dude.pcs.dec.com> (me@dude.pcs.dec.com)
next in thread | previous in thread | raw e-mail | index | archive | help
* > The current numbering scheme is correct. The "3" is the "protocal * > version" or something, and the "4" and the alphabet denote the major * > and minor shlib version numbers. Thus, 3.4e -> Xpm.4.5. * * Aaaaah, that actually makes sense, doesn't it? :-) Yeah...well it isn't *that* bad now, the only time it really confused us was when it was xpm-3.4c and libXpm.so.4.3.... * I see. This means we should be safe now until xpm-3.5 comes out * but that this then would mean work on the clients that use it * anyways, right? "that this then"? ;) Sorry I can't parse this...and I don't understand what xpm-3.5 does with this anyway, since the shared library will be libXpm.so.5.x.... * Would have been quite some hassle too - untarring all the packages * and ldd'ing the binaries. Maybe we should make it a rule that each * and every port should be installed on thud. Then clean them out * maybe once a month and try to rebuild and reinstall them. Then * make new packages. I think Andreas (ats) is doing this "rebuild all ports" somewhere, as I see lots of bug fixes from him. :) And about making new packages every month...well that's a lot of work, but if something is volunteering to do that, it would be great. * No, recompiling fvwm will generate a package identical to what is in * packages now (except for it using libXpm.so.4.*). In any case we should * be careful about generating packages that go into the ftp area on * -current machines. The libc minor version bump will hit everybody * who's just installed the latest SNAP and wants to get some packages * for his machine (something like "I want libc-2.1 but can only find * libc-2.0, I'm using it anyways) watch out for those bug reports :-(. Umm...well we are gearing full-speed towards the 2.1 CDROM now so I don't think we should stop building new packages. Maybe we can modify the .message that shows up when people enter wcarchive's ports/ area and say something about the libc minor version change, and also provide a gzipped binary for the new libc if that will solve the problem (and replacing the libc ONLY won't cause any other problems). * Right, the current package is at least incomplete. I've just tried it : * XFree86 install script. Dunno about fvwm, sorry. * Fixing the Makefile to copy the .xpm files and add them to the * package will be trivial. It's the other two points that need to be * addressed too at least for the 2.1 CD. I suggest removing the * fvwm package for now until it works. I'm willing to look into it * but can't promise to get this done before the end of next week. Great. I'll remove the package then, so please tell me when you are done (or just copy it to wcarchive yourself). * Btw. I'm baffled by the number of ports you manage to handle. A * quck grep finds 'asami' in the $Id$ strings of 64 makefiles. The * ports collection would be a lot less attractive without your work :-) Hey, you shouldn't look at $Id:$ lines for port owners...that's what MAINTAINER is for! :) And the reason why I show up in many ports' Makefiles is because I made a couple of modifications to bsd.port.mk recently and fixed a lot of Makefiles to work with the new .mk file, without even knowing what the ports do.... ;) Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503301001.CAA07314>