Notes on upgrades after libpcre update

Martin Matuska mm at FreeBSD.org
Thu Dec 13 14:24:30 UTC 2012


I agree.

On the other hand, we should also mark yet unmarked ports that directly
depend on pcre.
The main pain comes from glib20, ports using it are directly linked
against pcre but there is no information about this and we need this
documented.

I am releasing devel/pcre back to ports@, who wants can take care of it.

On 13.12.2012 10:56, Tijl Coosemans wrote:
> On 12-12-2012 10:03, Alex Dupre wrote:
>> Kevin Oberman ha scritto:
>>> As many of you noticed, the update of devel/pcre bumped hte version of
>>> libpcre.so which is a dependency of LOTS of things.
>> This was a very poor choice, we shouldn't have bumped the version. When
>> there is a bump between two minor releases (8.31 -> 8.32) a red led
>> should blink in port maintainer. The port should have defined:
>>
>> USE_AUTOTOOLS=  libtool
>> USE_GNOME=      ltverhack
>>
>> to avoid bumbing the version. In fact this is the diff in configure.ac:
>>
>> -m4_define(libpcre_version, [1:1:0])
>> -m4_define(libpcre16_version, [0:1:0])
>> +m4_define(libpcre_version, [3:0:2])
>> +m4_define(libpcre16_version, [2:0:2])
>>
>> It says that the new shared lib is compatible with the old lib (only new
>> interfaces were added), since:
>>
>> 1 - 0 = 3 - 2 = 1
>> 1 - 0 = 2 - 2 = 0
>>
>> (from the [current:revision:age] version = current - age rule)
> This should be mandatory knowledge for every ports committer.
>


-- 
Martin Matuska
FreeBSD committer
http://blog.vx.sk



More information about the freebsd-ports mailing list