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>>Details
Details
Q/A:
- portlint (looks fine.)
- testport (13.0-CURRENT, amd64; 12.1-RELEASE, i386)
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
| security/bsmtrace3/Makefile | ||
|---|---|---|
| 9 | 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 | I didn't check the tarball, but: Add LICENSE_FILE if one is provided in the distribution files | |
| 33 | 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. | |
Comment Actions
<pendantic-mentor>
New port commit log format:
[NEW] category/portname: $COMMENT <pkg-descr> <extra context if necessary>
</pedantic-mentor> :]
| security/bsmtrace3/pkg-descr | ||
|---|---|---|
| 5 | Can we change this to the github link? | |
| security/bsmtrace3/Makefile | ||
|---|---|---|
| 9 | +1 here for maintainership | |
| security/bsmtrace3/Makefile | ||
|---|---|---|
| 12 | Indeed, no LICENSE_FILE here. | |
| 33 | @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 | Done in my local copy | |
| security/bsmtrace3/Makefile | ||
|---|---|---|
| 33 | 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 | |