net-mgmt/p5-FusionInventory-Agent

[freebsd_simweb.ch]

Summary

Updates the FusionInventory-Agent to a rather much more recent version.

• The additional -Task ports can be dropped as upstream has integrated them into the main code of the agent.
• Most extra patches could be dropped as they are now part of upstream
• The HTTP option was replaced by DAEMON since the web server doesn't make sense without the DAEMON option
• pkg-plist only installs the manpages and executables when respective options are enabled

Isues known:

• We can't currently ship an rc script since launching in daemon mode creates a .pid file but doesn't contain the process ID
• It seems rc doesn't like daemons with dashes in the name (fusioninventory-agent fails, fusioninventory would work) so there is the question of the naming

Test Plan

• passes poudriere test port (does for me)
• can be launched with various options (does for me)
• can report to a GLPI+FusionInventory server plugin (TBD)

[mat]

phabricator does not show it, but some files were renamed, for example, patch-fix_install_paths into patch-Makefile.PL, be sure to say in the PR that the files were renamed so that it the history is kept.

net-mgmt/p5-FusionInventory-Agent/Makefile

16–22

Any reason for changing the order of the dependencies ? it adds unneeded changes to the Makefile.

41–42

Can it build if those ports are installed ? if so, this should be CONFLICTS_INSTALL.

[freebsd_simweb.ch]

In D4133#86989, @mat wrote:

phabricator does not show it, but some files were renamed, for example, patch-fix_install_paths into patch-Makefile.PL,
be sure to say in the PR that the files were renamed so that it the history is kept.

OK, will do so in the PR. I chose to do so in order to make portlint spit less at me. (The PR isn't opened yet but I'll note it)

net-mgmt/p5-FusionInventory-Agent/Makefile

16–22

Upstream conveniently sorts its dependencies in its Makefile.PL in alphabetical orderi.
If we stick to that as well it makes tracking changes of dependencies easier.
Technically not needed but for future convenience it would be nice and simplifies updates.

41–42

Good question, let's me check back on that.

[freebsd_simweb.ch]

(See inline comment)

net-mgmt/p5-FusionInventory-Agent/Makefile

41–42

(It looks like for what i can tell) that it can effectively build since, well it's Perl modules in the end.

However, since they seem to install in the same directories it may remove files if you upgrade first the Agent and then
remove the -Task ports it may lead to an inconsistent state. I'm not an expert there, what would you prefer?

[bofh]

Any ideas when this is going to be committed if builder testing is completed. I want to mark one of the conflicts as DEPRECATED. Based on the commit I will give a 30 day expiration notice. I believe vg@ is unavailable.

[freebsd_simweb.ch]

In D4133#89460, @bofh wrote:

Any ideas when this is going to be committed if builder testing is completed.

It has passed poudriere testport here so far, I've checked back with mats input I hope all questions were answered so far.

I want to mark one of the conflicts as DEPRECATED. Based on the commit I will give a 30 day expiration notice.

Cool, since it is in effect a duplication once this one hits the ports tree.

I believe vg@ is unavailable.

Then it requires someone to commit since I am not a ports commiter.
If vg@ wants to, I'd offer to take the maintainership of this port, but that requires his OK I'd expect.

[mat]

In D4133#89460, @bofh wrote:

Any ideas when this is going to be committed if builder testing is completed. I want to mark one of the conflicts as DEPRECATED. Based on the commit I will give a 30 day expiration notice. I believe vg@ is unavailable.

This is a code review tool, not a bug tracking system. There is no maintainer timeout here. If this update needs to be put into a patch, and entered into bugzilla. When that is done, the maintainer timeout process starts, and the current maintainer has two weeks to do something.

[freebsd_simweb.ch]

In D4133#89798, @mat wrote:

This is a code review tool, not a bug tracking system.

Already done here is the PR as cross-reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204632

There is no maintainer timeout here. If this update needs to be put into a patch, and entered into bugzilla.

I'll put up this patch to the mentioned PR

When that is done, the maintainer timeout process starts, and the current maintainer has two weeks to do something.

No worries for me.

• Mathieu

[dbaio]

It landed in ports r408042
Just accepting for close it after.