cvs commit: ports/graphics/eog-plugins Makefile ports/graphics/shotwell Makefile ports/graphics/ethumb Makefile ports/multimedia/dvdstyler Makefile ports/multimedia/mlt Makefile ports/net/mediatomb Makefile ports/net/minidlna Makefile ports/sysut

[Boris Samorodov]

On Fri, 4 Mar 2011 19:07:27 +0800 wen heping wrote:

> Also libexif.12.so did not change the shlib version, I knew from upstream
> this is a security update ,

Good, but that is the main purpose of PORTREVISION -- force updating
of the port.

Bad, because:
. you didn't update our security database (security/vuxml);
. you said nothing about security updates at the commit log.

> so I think there should be something changed
> in the shlib.

Sure, the library was changed. But we are talking about the shlib
*number*.

> I think it is safe and worthy to force all the user rebuild their
> package which depend on libexif.

Seems you don't understand why a PORTREVISION (hence a dependent ports
rebuilding) is needed. Look:
-----
% ldd `which zsh`
/usr/local/bin/zsh:
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28110000)
        libncursesw.so.8 => /lib/libncursesw.so.8 (0x28206000)
        libm.so.5 => /lib/libm.so.5 (0x2824c000)
        libc.so.7 => /lib/libc.so.7 (0x28265000)
%
-----

Zsh LIB_DEPENDS upon (in port's Makefile terms) iconv.3. When a new
version of libiconv with a shlib bump appears and is installed,
the system has libiconv.so.4 library (I'm not speaking about compat
here). The shell becomes useless -- it won't run. To prevent this
the PORTREVISION of shells/zsh should be bumped.

But if a new libiconv library (say, with a security fix) is installed,
then *nothing* should be done with shells/zsh! The latter just use the
new library.

-- 
WBR, bsam