Hi,
Am Freitag, März 09, 2018 10:54 CET, Stuart Henderson <s...@spacehopper.org>
schrieb:
> On 2018/03/09 01:59, Klemens Nanni wrote:
> > On Thu, Mar 08, 2018 at 11:23:52AM +0100, Sebastian Reitenbach wrote:
> > > Index: Makefile
> > > ===================================================================
> > > RCS file: /cvs/ports/www/sogo/Makefile,v
> > > retrieving revision 1.74
> > > diff -u -r1.74 Makefile
> > > --- Makefile 11 Jan 2018 19:27:12 -0000 1.74
> > > +++ Makefile 8 Mar 2018 09:46:46 -0000
> > > @@ -2,15 +2,15 @@
> > >
> > > COMMENT = web based groupware server
> > >
> > > -VERSION = 3.2.10
> > > +VERSION = 4.0.0
> > > DISTNAME = SOGo-${VERSION}
> > > PKGNAME = sogo-${VERSION}
> > > REVISION = 1
> > Zap REVISION.
> >
> > > SHARED_LIBS += GDLContentStore 3.0
> > > -SHARED_LIBS += NGCards 3.0
> > > -SHARED_LIBS += SOGo 4.1
> > > -SHARED_LIBS += SOGoUI 2.1
> > > +SHARED_LIBS += NGCards 3.1
> > > +SHARED_LIBS += SOGo 5.0
> > > +SHARED_LIBS += SOGoUI 2.2
> > >
> > > CATEGORIES = www
> > > HOMEPAGE = http://www.sogo.nu/
> > https://sogo.nu works.
> >
> > > @@ -72,8 +72,14 @@
> > > ${WRKSRC}/Scripts/sql-update-2.2.17_to_2.3.0.sh \
> > > ${PREFIX}/share/doc/sogo/sql-update-2.2.17_to_2.3.0-postgres.sh
> > > ${INSTALL_SCRIPT} -c -o ${SHAREOWN} -g ${SHAREGRP} \
> > > + ${WRKSRC}/Scripts/sql-update-3.2.10_to_4.0.0.sh \
> > > + ${PREFIX}/share/doc/sogo/sql-update-3.2.10_to_4.0.0-postgres.sh
> > > + ${INSTALL_SCRIPT} -c -o ${SHAREOWN} -g ${SHAREGRP} \
> > > ${WRKSRC}/Scripts/sql-update-2.2.17_to_2.3.0-mysql.sh \
> > > ${PREFIX}/share/doc/sogo/sql-update-2.2.17_to_2.3.0-mysql.sh
> > > + ${INSTALL_SCRIPT} -c -o ${SHAREOWN} -g ${SHAREGRP} \
> > > + ${WRKSRC}/Scripts/sql-update-3.2.10_to_4.0.0-mysql.sh \
> > > + ${PREFIX}/share/doc/sogo/sql-update-3.2.10_to_4.0.0-mysql.sh
> > > ${INSTALL_SCRIPT} -c -o ${SHAREOWN} -g ${SHAREGRP} \
> > > ${WRKSRC}/Scripts/sql-update-3.0.0-to-combined.sh \
> > > ${PREFIX}/share/doc/sogo/sql-update-3.0.0-to-combined.sh
> > I'd really simplify these into a loop to shorten the target and ease
> > reading:
> >
> > .for _s in ...
> > ${INSTALL_SCRIPT} ... \
> > ${WRKSRC}/Scripts/..${_s}.. \
> > ${PREFIX}/share/doc/sogo/..${_s}..
> > .endfor
>
> Wouldn't it be better to use upstream's standard names? Then a simple
> wildcard works, it matches their usual setup, and you don't have the
> inconsistency you have here where some files are renamed with
> -postgres and others aren't.
yeah, with the loop in my updated version, I use the standard names, and
I dropped some legacy scripts.
>
> > > RCS file: patches/patch-Scripts_sql-update-3_2_10_to_4_0_0-mysql_sh
> > > diff -N patches/patch-Scripts_sql-update-3_2_10_to_4_0_0-mysql_sh
> > > --- /dev/null 1 Jan 1970 00:00:00 -0000
> > > +++ patches/patch-Scripts_sql-update-3_2_10_to_4_0_0-mysql_sh 8 Mar
> > > 2018 09:46:46 -0000
> > > @@ -0,0 +1,68 @@
> > > +$OpenBSD$
> > > +
> > > +Index: Scripts/sql-update-3.2.10_to_4.0.0-mysql.sh
> > > +--- Scripts/sql-update-3.2.10_to_4.0.0-mysql.sh.orig
> > > ++++ Scripts/sql-update-3.2.10_to_4.0.0-mysql.sh
> > > +@@ -1,4 +1,4 @@
> > > +-#!/bin/bash
> > > ++#!/bin/sh
> > Does the script work with our ksh?
>
> I don't think so.
>
> read -p "Username ($defaultusername): " username
> read -p "Hostname ($defaulthostname): " hostname
> read -p "Database ($defaultdatabase): " database
>
> bash:
>
> -p prompt
> Display prompt on standard error, without a trailing newline, before
> attempting to read any input. The prompt is displayed only if input
> is coming from a terminal.
>
> ksh:
>
> The -un and -p options cause input to be read from file descriptor
> n
> (n defaults to 0 if omitted) or the current co-process (see Co-
> processes above for comments on this), respectively. If the -s
> option is used, input is saved to the history file.
>
> > > # su _sogo "${TRUEPREFIX}/bin/bash
> > > ${TRUEPREFIX}/share/doc/sogo/sql-update-3.0.0-to-combined.sh"
> > > # su _sogo "${TRUEPREFIX}/bin/bash
> > > ${TRUEPREFIX}/share/doc/sogo/sql-update-3.0.0-to-combined-mysql.sh"
> > bash is already missing from RUN_DEPENDS, I wonder if users tried to run
> > that instruction but failed.
>
> I would have a good look at the sed invocations in that file and make sure
> they don't rely on anything from GNU sed.
>
