patch for spec against 1.3.3.9 to split out snmp support to a sub package
389-ds-base-snmp.patch

I've tested the attached spec patch against F-22 and rawhide.

This issue is critical for F-24. Note that the spec changes will also have to be made to Fedora dist-git, and eventually to downstream rpm spec repos (e.g. EL).

I am not opposed to splitting the SNMP subagent out into a separate subpackage, but we need to carefully consider how upgrades will be handled. If someone is using the SNMP subagent in an older release that includes it in the 389-ds-base package, we don't want to remove it and break their monitoring upon upgrade. This will be difficult since the intent is to make the SNMP subagent an optional package.

Replying to [comment:6 nkinder]:

I am not opposed to splitting the SNMP subagent out into a separate subpackage, but we need to carefully consider how upgrades will be handled. If someone is using the SNMP subagent in an older release that includes it in the 389-ds-base package, we don't want to remove it and break their monitoring upon upgrade. This will be difficult since the intent is to make the SNMP subagent an optional package.

No it won't in terms of existing upgrades, it's quite straight forward to do with Obsoletes/Provides and is done on a regular basis in Fedora to deal with the exact problem described all the while enabling either it to be not present in new installs or to be removed post upgrade if the user wishes. I can review/update the patch to deal with this if it's not going to be ignored and a waste of my time.

Replying to [comment:7 pbrobinson]:

No it won't in terms of existing upgrades, it's quite straight forward to do with Obsoletes/Provides and is done on a regular basis in Fedora to deal with the exact problem described all the while enabling either it to be not present in new installs or to be removed post upgrade if the user wishes. I can review/update the patch to deal with this if it's not going to be ignored and a waste of my time.

Ok, that approach makes sense.

We have raised the priority of this and put it into our "triage" milestone, which we go through weekly. We will get this addressed for F-24. If you do have the time to update the patch, that would be great. If not, it is no problem for us to update it on our side.

An practical example how to handle upgrade from monolithic package to two sub-packages can be seen in FreeIPA git: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f1f3ef478d8d2786269a919bb428cb2ee5372ba6

Basically both subpackages need to have
{{{
Obsoletes: <original package name> <= <latests monotlithic package version>
}}}

That is enough for proper handling of upgrades but it allows on new installs to get only subpackage.

Is this just going to be constantly moved from milestone to milestone and constantly not done anything for a simple fix?

Replying to [comment:13 pbrobinson]:

Is this just going to be constantly moved from milestone to milestone and constantly not done anything for a simple fix?
Sorry, will be included in the next respin.

git patch file (master)
0001-Ticket-47911-split-out-snmp-agent-into-a-subpackageT.patch

Patch looks good to me.

Reviewed by William (Thank you!!)

Pushed to master:
8269288..2252acd master -> master
commit 2252acd

attachment
0001-Ticket-47911-Move-dirsrv-snmp.service-to-389-ds-base.patch

Looks good. Thanks for the patch, Viktor!

Pushed the patch to the upstream repository on behalf of Viktor. (Thanks, Viktor!!)

c984499..e31b324 master -> master
commit e31b324

136b366..f49bd60 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
commit f49bd60

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1242

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.