On Sat, Jan 26 2019, Nam Nguyen <namn@berkeley.edu> wrote:
>> Upstream still has FTP so please leave the ftp:// URL in so that "make
>> peek-ftp" works.
> OK I left ftp://.
>
>> Have you looked at the update to 10.32?
> Here is my attempt. I am new to ports, so I need help with respect to
> understanding bumping major.minor of shared libraries.
>
> The API has remained the same. No functions were added or removed.
>
> I included some interesting snippets from the changelog and looked out
> for reasons to bump the major, primarily "valid calling sequences are no
> longer valid."
>
> Only items #21 and #39 seem like they might qualify (as in something
> that used to work before but no longer works). However, these seem so
> insignificant (and based on CVS history) that I believe this should be
> minor bumps across the board?
Unless I missed something you didn't mention a reason to even bump the
minor. No symbols have beed added/removed, no structures or function
signatures have been changed. *But* there are new error codes exposed
in pcre2.h, so technically some consumers might depend on it, thus
I think a minor bump makes sense.
> What does 3.0 mean in "0.1 # 3.0" mean?
It's what would have been used by the build system if we had not
overriden the version number in ports.
> I see that 0.1 is major.minor.
> ${WRKBUILD}/shared_libs.log can be included in the port's Makefile. Is
> this only useful in initially drafting a new port and not so much in
> updating a port?
It's not even useful when starting a port, since we completely ignore
upstream's choices and start at 0.0. I try to update those markers when
I can, but I think it's usually a lost cause. Some upstreams don't
properly bump the major/minor when due, and some upstreams bump the
major/minor even when not needed. So a porter has to make her own
checks anyway, and the marker has little value.
The test suite (RunGrepTest) could be tweaked to either use gsed(1) or
work around the failing test, but that can be done later. With
a patched RunGrepTest, tests already pass on amd64 with 10.31, and also
pass on amd64 and sparc64 with 10.32.
I'm going to commit this, minus one nit below (no need to resend a diff),
> For testing, I built the new wget against pcre2 and downloaded an
> OpenBSD install64.iso.
>
> Changelog: https://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup&pathrev=1001
> ----8<------------------------------------------------------------
> 1. When matching using the the REG_STARTEND feature of the POSIX API with a
> non-zero starting offset, unset capturing groups with lower numbers than a
> group that did capture something were not being correctly returned as "unset"
> (that is, with offset values of -1).
>
> 21. In both pcre2test and pcre2_substitute(), with global matching, a pattern
> that matched an empty string, but never at the starting match offset, was not
> handled in a Perl-compatible way. The pattern /(<?=\G.)/ is an example of such
> a pattern. Because \G is in a lookbehind assertion, there has to be a
> "bumpalong" before there can be a match. The automatic "advance by one
> character after an empty string match" rule is therefore inappropriate. A more
> complicated algorithm has now been implemented.
>
> 35. In a pattern such as /[^\x{100}-\x{ffff}]*[\x80-\xff]/ which has a repeated
> negative class with no characters less than 0x100 followed by a positive class
> with only characters less than 0x100, the first class was incorrectly being
> auto-possessified, causing incorrect match failures.
>
> 39. If the only branch in a conditional subpattern was anchored, the whole
> subpattern was treated as anchored, when it should not have been, since the
> assumed empty second branch cannot be anchored. Demonstrated by test patterns
> such as /(?(1)^())b/ or /(?(?=^))b/.
>
> 40. A repeated conditional subpattern that could match an empty string was
> always assumed to be unanchored. Now it it checked just like any other
> repeated conditional subpattern, and can be found to be anchored if the minimum
> quantifier is one or more. I can't see much use for a repeated anchored
> pattern, but the behaviour is now consistent.
> ----8<------------------------------------------------------------
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/pcre2/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile 14 Nov 2018 20:48:21 -0000 1.7
> +++ Makefile 26 Jan 2019 22:58:51 -0000
> @@ -2,20 +2,23 @@
>
> COMMENT = perl-compatible regular expression library, version 2
>
> -DISTNAME = pcre2-10.31
> +DISTNAME = pcre2-10.32
> REVISION = 0
REVISION should be dropped when performing an update.
>
> -SHARED_LIBS += pcre2-16 0.1 # 3.0
> -SHARED_LIBS += pcre2-32 0.1 # 3.0
> -SHARED_LIBS += pcre2-8 0.2 # 3.0
> -SHARED_LIBS += pcre2-posix 0.1 # 0.1
> +SHARED_LIBS += pcre2-16 0.2 # 3.0
> +SHARED_LIBS += pcre2-32 0.2 # 3.0
> +SHARED_LIBS += pcre2-8 0.3 # 3.0
> +SHARED_LIBS += pcre2-posix 0.2 # 0.1
>
> CATEGORIES = devel
>
> -MASTER_SITES = http://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ \
> +MASTER_SITES = https://ftp.pcre.org/pub/pcre/ \
> + ${MASTER_SITE_SOURCEFORGE:=pcre/} \
> + http://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ \
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
>
> -HOMEPAGE = http://www.pcre.org/
> +HOMEPAGE = https://www.pcre.org/
> +MAINTAINER = Nam Nguyen <namn@berkeley.edu>
>
> # BSD
> PERMIT_PACKAGE_CDROM = Yes
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/devel/pcre2/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 26 Apr 2018 13:06:01 -0000 1.3
> +++ distinfo 26 Jan 2019 22:58:51 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (pcre2-10.31.tar.gz) = 4R69md0jp7zMkSfZXZl4EBtfPPCm59JaGxyhZalxZsQ=
> -SIZE (pcre2-10.31.tar.gz) = 2130574
> +SHA256 (pcre2-10.32.tar.gz) = nKm+cuGgTyK+MIMjyqjAbr0MUe/pnuESeBhsr7xP468=
> +SIZE (pcre2-10.32.tar.gz) = 2169349
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
No comments:
Post a Comment