svn commit: r417895 - in head/net: ndpi ntopng

[Guido Falsi]

On 07/02/16 22:01, Mathieu Arnold wrote:
> +--On 1 juillet 2016 20:04:34 +0200 Guido Falsi <madpilot at FreeBSD.org>
> wrote:
> | On 07/01/16 18:58, Baptiste Daroussin wrote:
> |> On Fri, Jul 01, 2016 at 04:49:09PM +0000, Guido Falsi wrote:
> |>> Author: madpilot
> |>> Date: Fri Jul  1 16:49:09 2016
> |>> New Revision: 417895
> |>> URL: https://svnweb.freebsd.org/changeset/ports/417895
> |>> 
> |>> Log:
> |>>   - Update ndpi port to a newer snapshot from github, required by
> |>>     ntopng update
> |>>   - Update ntopng to 2.4
> |>> 
> |>> Modified:
> |>>   head/net/ndpi/Makefile
> |>>   head/net/ndpi/distinfo
> |>>   head/net/ntopng/Makefile
> |>>   head/net/ntopng/distinfo
> |>>   head/net/ntopng/pkg-plist
> |>> 
[...]
> |>> +USE_GITHUB=	yes
> |>> +GH_ACCOUNT=	ntop
> |>> +GH_PROJECT=	nDPI
> |>> +GH_TAGNAME=	6fb81f1
> |>> +
> |> You could use the tags instead of adding GH_TAGNAME, there is a "1.8"
> |> tag, so removing the GH_TAGNAME entirely should just fetch the same
> |> sources (distfile name will change)
> | 
> | Unluckily I cannot. This isn't the 1.8 tag, but a commit slightly ahead
> | of it in the 1.8-stable branch. There is no tag referencing it.
> 
> If this is not 1.8, it should not be called 1.8 but 1.8.1 or similar.
> 

The upstream did not create a new version, which is something I cannot
do. I would just lie by marking the port as 1.8.1 if there is no 1.8.1
release upstream.

The commit I am taking is just a few commits ahead of the 1.8 tag and
contains fixes which I could have imported as patches i files, like we
are doing all the time (I mean importing upstream patches), I did prefer
to just move ahead on the upstream repository for coherence with their
sources.

The upstream is creating packages themselves for other OSes, and they do
that by bundling this same version of the nDPI sources in the ntopng
source packages. For binary packages they statically link this same nDPI
version in ntopng. I could follow suit in the ntopng port and just
statically link to the bundled ndpi library, but since we do have a
separate ndpi port I thought it was better to dynamically link to it and
keep ii up to date.

Apart from talking to the upstream and ask them to tag minor releases
(which I'm going to do BTW, I just need time ti coordinate about this) I
have these options(in random order):

- add a date to the ndpi version (like 1.8.2016.07.02) to differentiate
from the 1.8 tag (imho this is overkill for just a few small
modifications from upstream)

- revert my last commit opn ndpi and disengage the ntopng port from it,
using a statically linked ndpi in it like upstream is doing (which would
anyway come from the same sources ndpi port is using a t present)

- maybe create a ndpi-stable port? this would definitely be overkill.

- point the port at the tag and cherry pick some fixes from upstream as
local patches in files. This would be just formally different from what
I'm doing now.

I'm open to suggestions, but I don't see the present situation as
terribly wrong.

-- 
Guido Falsi <madpilot at FreeBSD.org>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 502 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20160703/f433162f/attachment.sig>