Page MenuHomeFreeBSD

New port: security/bsmtrace3
ClosedPublic

Authored by kevans on Apr 16 2020, 2:09 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, May 18, 2:33 AM
Unknown Object (File)
Fri, May 3, 7:35 AM
Unknown Object (File)
Sat, Apr 20, 6:55 PM
Unknown Object (File)
Sat, Apr 20, 6:55 PM
Unknown Object (File)
Sat, Apr 20, 6:55 PM
Unknown Object (File)
Apr 19 2024, 6:15 AM
Unknown Object (File)
Mar 18 2024, 3:43 PM
Unknown Object (File)
Feb 1 2024, 4:37 PM
Subscribers

Details

Summary
New port: security/bsmtrace3

This is a repocopy of security/bsmtrace, updated to recently-released 3.x. There are breaking changes between 1.x and 3.x, so it was decided to create a new port to give consumers some time to update their configs. The old security/bsmtrace should be deprecated in fairly short order, after bsmtrace3 has received a little bit of soak time in ports.

bsmtrace 3.x, compared to the previous port, offers following new features:
- Set arrays will now resize on the fly, so the size limits should be no more
- Logging channels have been removed, there's now one `logfile` directive that can be applied at the global level to switch the logfile (assuming the -l logdir option is in use) 
- Other config files can now be included with the 'include' directive; globs are not currently supported, paths are relative to the primary config file
- Sequences can now be configured to match on the jail name with the per-sequence `zone` directive; valid values are: any, none, or a glob string that matches the jail name. Any = any jail, not the host. None = Only the host, no jails.

Other points:
- The Makefile patch is no longer needed as PCRE is now a mandatory dependency.
- The dprintf(3) conflict is no more, so the rest of the patches also disappear.
- This port now installs manpages to ${PREFIX}/share/man as per recent guidelines to reflect base hierarchy.

Approved by: koobs (mentor) or bapt (mentor)
Differential_Revision: <<this>>
Test Plan

Q/A:

  • portlint (looks fine.)
  • testport (13.0-CURRENT, amd64; 12.1-RELEASE, i386)

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

security/bsmtrace3/Makefile
9 ↗(On Diff #70632)

Usually new ports (all else being equal) should be maintained by their authors., but of course repocopies are interesting cases.

Since it wasn't explicitly mentioned, this is just for learning:

Is csjp happy to maintain this?

I anticipate since bsdtrace will be exevntually 3.x, that there's no maintainer change here accordingly.

Having said that, since this port will be short lived, perhaps you should maintain it, if nothing else than not have to have min_timeout= 2 weeks for any changes you want to make.

12 ↗(On Diff #70632)

I didn't check the tarball, but:

Add LICENSE_FILE if one is provided in the distribution files

33 ↗(On Diff #70632)

Might this be be a good opportunity to install these things as bsmtrace3*, not have it CONFLICT with bsmtrace, and perhaps aid migrations?

Your call however.

<pendantic-mentor>

New port commit log format:

[NEW] category/portname: $COMMENT

<pkg-descr>

<extra context if necessary>

</pedantic-mentor> :]

security/bsmtrace3/pkg-descr
5 ↗(On Diff #70632)

Can we change this to the github link?

security/bsmtrace3/Makefile
9 ↗(On Diff #70632)

+1 here for maintainership

kevans added inline comments.
security/bsmtrace3/Makefile
12 ↗(On Diff #70632)

Indeed, no LICENSE_FILE here.

33 ↗(On Diff #70632)

@csjp -- thoughts? I lean towards not worrying about it, as the migration paths will generally be start it up and quickly realize which parts of their config have been invalidated and those are easy to remediate as most changes will be to just remove any log channel config.

security/bsmtrace3/pkg-descr
5 ↗(On Diff #70632)

Done in my local copy

security/bsmtrace3/Makefile
33 ↗(On Diff #70632)

I think it's fine to have it conflict. The bsmtrace vs bsmtrace3 pattern has always slightly annoyed me. Having said that, I don't have any strong opinions about it one way or another. I would probably defer to what the ports folks would prefer

This revision is now accepted and ready to land.Apr 21 2020, 4:39 AM
This revision was automatically updated to reflect the committed changes.
kevans marked an inline comment as done.