I know it is not really related to this patch but you can replace

Requires(post):   systemd-units
Requires(preun):  systemd-units
Requires(postun): systemd-units

with rpm macro "{?systemd_requires}" which is even in el7.

Comment from patch in different project

The rpm macro systemd_requires is even in el7 and using this macro
nicer then using different requires (systemd-units vs systemd)
There is a plan to remove provides for systemd-units from rawhide.

systemd was added to BuildRequires because it provides rpm macros
/usr/lib/rpm/macros.d/macros.systemd and it is unreliable to rely
on indirect dependency between systemd-devel and systemd

sh$ rpm --eval "%{?systemd_requires}"

Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd

sh$ rpm -q --whatprovides systemd-units
systemd-237-1.fc28.x86_64

sh$ rpm -qf /usr/lib/rpm/macros.d/macros.systemd
systemd-237-1.fc28.x86_64

Thanks @lslebodn that's a good idea. I've updated it accordingly.

Could you also please add Obsoletes section for legacy-tools subpackage, similar to snmp subpackage for upgrade/downgrade purposes?

You know, I don't think we should add the obsoletes. The point is to NOT have this package on an upgrade, it's only there as a stop gap in case we miss somethig.

Having it "present" on upgrade defeats this purpose,

So I don't want to add the obsoletes here.

William, please consider these scenarios:
1. Fresh install.
With and without "Obsoletes" section perl tools are not installed.
2. Upgrade from 1.3.x
With "Obsoletes" perl tools package is installed, since we can't know for sure if these scripts were used by admins or not. We can't make decision for them, because if we choose not to install the scripts, this might break their systems, scheduled backups, etc.
3. Downgrade from 1.4.x to 1.3.x
With "Obsoletes" in place package manager will correctly suggest to remove conflicted package. Without there will be an error saying that old 389-ds-base and installed perl tools package have files that belong to different packages. This is basic package sanity and we should adhere to packaging guidelines.

Having it "present" on upgrade defeats this purpose,

What is the purpose here? As far as I remember, we agreed that we won't remove perl tools suddenly and completely. Instead we will provide a legacy perl tools package, so that users can migrate from perl to python. And after some time we will remove it completely. Without "Obsoletes" we're not giving time to our users to safely migrate from perl scripts.

William, please consider these scenarios:
1. Fresh install.
With and without "Obsoletes" section perl tools are not installed.

Correct

1. Upgrade from 1.3.x
   With "Obsoletes" perl tools package is installed, since we can't know for sure if these scripts were used by admins or not. We can't make decision for them, because if we choose not to install the scripts, this might break their systems, scheduled backups, etc.

This is the important one. We DO want to remove this. The fact we are keeping the perl tools at all between 1.3.x -> 1.4.x is only as a "fallback" if something goes wrong. We are 100% deprecating and removing these tools. No exceptions. So admins will either have to go "ohh noes" and work out how to work without these tools - or they install the legacy tools package and have a short grace period. This is exactly why I'm not adding them.

1. Downgrade from 1.4.x to 1.3.x
   With "Obsoletes" in place package manager will correctly suggest to remove conflicted package. Without there will be an error saying that old 389-ds-base and installed perl tools package have files that belong to different packages. This is basic package sanity and we should adhere to packaging guidelines.

I don't think we really support downgrades properly ... I can certainly think of a few things that will go badly if this happens. Saying this, having it remove the legacy tools on a downgrade is a good thing ....

Having it "present" on upgrade defeats this purpose,

What is the purpose here? As far as I remember, we agreed that we won't remove perl tools suddenly and completely. Instead we will provide a legacy perl tools package, so that users can migrate from perl to python. And after some time we will remove it completely. Without "Obsoletes" we're not giving time to our users to safely migrate from perl scripts.

Giving them the package doesn't mean giving it by default. It means it's available if you "have" to still need it, but we won't be giving it to you on an upgrade.

To put this another way: if we put the legacy package in "obsoletes" then it's there on upgrade, and admins have no idea it's going away. Then it IS a hard removal when we get rid of this subpackage in the future.

This way, at least there is something they can fall back to when they notice it's gone. We want to encourage people to use the new tools, not "give them as many options as they can to avoid it by default".

I have to disagree. This breaks upgrade/downgrade path and basic package sanity. Moreover, changes likes this should be communicated properly through release notes and announcements. So that admins will have an idea that something is going away. We need to make sure that from our side we did everything possible to communicate the changes and provided a working upgrade path.

This particular change can go in upstream spec file. But in downstream there are tests (TPS in Errata Workflow) that will scream if upgrade/downgrade is broken, preventing these packages to be released.

We are saying that it's going away, and we then have a fallback. But installing the "fallback on upgrade" is wrong. We are adding a new subpackage, and moving things to it. We shouldn't installing fallbacks "by default".

The alternate was a hard line in the sand where these tools don't exist.

I'm surprised that RPM can't handle this situation tbh .... :(

okay,. How about this compromise.

We add the obsoletes BUT we completely remove setup-ds.pl. This way people don't use it.

Alternately, we rename setup-ds.pl.

Would this work?

Migration from major versions of RHDS is supported via export/import method or replication method, see [1]. In-place upgrade is not supported officially (even though it can be technically done).

Since this will be a part of next major version, I think it's ok to have a clean slate and not install legacy tools by default. We should also move to python installer.

That leaves us with Fedora (other distros can do packaging differently), where in-place upgrade is supported.

So, for RHEL we can drop Obsoletes, for Fedora we should have it. These changes are done in their dist-git. Change discussed here is in the upstream spec file only, so I'm fine with that.

[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/installation_guide/Database_Migration_Methods

This have stalled a bit. I reviewed recommendations for in-place upgrade for RHEL and we must have Obsoletes there. Upstream spec file missing Obsoletes is also bad, since I can't upgrade/downgrade packages from official repos and built by make rpms on my test systems. So we must have Obsoletes either way.

Lets get this moving! I'm taking this over and filing a PR to continue the review process

https://pagure.io/389-ds-base/pull-request/49756

This patch on top of PR 49756 solves upgrade issues.

Another patch to address issues in https://pagure.io/389-ds-base/pull-request/49756#comment-54895

I noticed that output2 is not used anymore, its usage was removed in 1fe2c76. So if this is really not needed, we can remove it completely from the scriptlet.

Applied to PR...

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/2630

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.