#47911 split out snmp agent into a subpackage
Closed: wontfix None Opened 6 years ago by rmeggins.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1146030

Created attachment 940737
Initial spec patch to split snmp functionality to sub package

The snmp agent is optional functionality and hence should be available as a
subpackage to allow removal including and dependencies it might need that are
otherwise not required for a standard 389-ds-base operational LDAP instance.

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.

Patch looks good to me.

Reviewed by William (Thank you!!)

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

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

Metadata Update from @rmeggins:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.5.5

4 years ago

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

8 months ago

Login to comment on this ticket.

Metadata