Add Port to FreeBSD Ports

FWITW: I have been toying with the concept of by-passing the the ports and just providing a pkg for some of my tools.
-i.e., I've automated the pkg making process on my local git server so when I do a push, a pkg is built. I was contemplating the idea of automating the upload step to a GitHub release (for other people to use) but am currently focused on "internal (LAN) distribution" instead, at the moment. The mechanism for automated remote deployment is built and tested but I'm just too lazy to finish. lol
 
About rebuilding everything ... had a conversation with "a dev" on bugzilla.
The guy just deleted the thread ... a bit arrogant ...
Some port ... have 1000's of dependent ports.
Normally only a rebuild is needed when the ABI changes.
In practice and currently this is not the case.
Currently rebuilding 1000 of packages due to this.
 
About rebuilding everything ... had a conversation with "a dev" on bugzilla.
The guy just deleted the thread ... a bit arrogant ...
Some port ... have 1000's of dependent ports.
Normally only a rebuild is needed when the ABI changes.
In practice and currently this is not the case.
Currently rebuilding 1000 of packages due to this.
For fundamental ports that are depended upon a plenty of ports, upgrades for them causes poudriere causes a plenty of ports to be forcibly rebuilt on poudriere "by default". It would be because devs of poudriere suspect "hidden breaking changes", means, "breaking changes without library version bumps", and clearly the safest way with the costs of "possibly unneeded at all massive rebuilds".

For this case, if you're sure there are no breaking changes, you can specify option "-S" for `poudriere bulk ...`.

And for base OS upgrades (in case you've upgrading poudriere jails with it), the option "-S" cannot help at all. Poudriere always attempts to rebuild everything when (as far as I've encountered):
  • OSVERSION which comes from __FreeBSD_version in /usr/include/sys/param.h is bumped even with least significant digit.
  • Whichever REVISION or BRANCH is somehow modified in /usr/src/sys/conf/newvers.sh.
There could be more, though. And this is unavoidable as far as I know.
 
vermaden When you get a chance, consider an article on what to do when an existing port needs updating. For example:
  • who do I contact when a new version is available?
  • what can be done if there is no maintainer?
  • how to get a fix added to the port?
  • how to become a maintainer of a port?
  • do I need to be a ports-committer to be a port maintainer?
  • and so on.
 
vermaden When you get a chance, consider an article on what to do when an existing port needs updating. For example:
  • who do I contact when a new version is available?
  • what can be done if there is no maintainer?
  • how to get a fix added to the port?
  • how to become a maintainer of a port?
  • do I need to be a ports-committer to be a port maintainer?
  • and so on.
Which ports do You currently maintain?
 
who do I contact when a new version is available?
To the maintainer. But they should be notified by portscout unless explicitly opted out with some reason.

  • what can be done if there is no maintainer?
  • how to get a fix added to the port?
File a PR on Bugzilla. If you have patch to upgrade, Phabricator would be better. If no one handles it, ping to freebsd-ports ML could help if there are someone interested.

how to become a maintainer of a port?
File a PR on Bugzilla with a patch changing MAINTAINER= line with your active email address. Other changes can be included, too.
At the time, you'll need "Take maintainership" line in description among others.

do I need to be a ports-committer to be a port maintainer?
No need to be a committer. But assignee of the PR is needed to be a committer (before, non-committer maintainer was OK, though).

Frankly, it's in reverse.
If you're doing good jobs as a maintainer of multiple ports for a long time, you could be given a chance to become a committer.
But committers has more duty and responsibilities compared with non-committer maintainers. See Committer's Guide for what are required.
 
Some kind of changes can be committed without explicit reviews / permissions (blanket approval).

And not documented in the above one, if I understanding correctly, blanket approval for merging commits on main (aka latest) into quarterly includes security-only fixes, build time / runtime fixes caused by changes commit to base, if the changes are trivial.

All other merges into quarterly needs explicit approval of portmgr and/or secteam (my understanding, though). Bugzilla has merge-quarterly flag for this purpose.
 
Back
Top