start-dirsrv, db2ldif, etc, these scripts do not use perl, they are shell scripts.

These are shell scripts, why are they under "if perl"?

Because they aren't needed with lib389, and we shouldn't be maintaining them any longer? I think that's why I included them in the exclusion.

Thanks William for reminding me, first I thought I went nuts back then. Yeah, the problem is we don't have a concept of "legacy-tools" in the build system, only in the SPEC file. However, once you build something you should also install it in the SPEC file (yeah, you could just remove these after building but that ain't much transparent given SPEC build should be as close to pure build as possible).

So a question might be: Do we want to introduce the concept of "legacy-tools" into the build system?

It might be a nicer line than perl vs lib389, because really it's legacy (perl + sh) vs lib389. But I wish william of the past had of thought about this better and made it --disable-legacy instead of --disable-perl.

So my issue is that we already have the legacy tool subpackage, then inside of the legacy tools we differentiate the perl scripts. So it's already mismatched IMO. So what do we need a "if perl" check for? It should be legacy tools or no legacy tools, right?

So my issue is that we already have the legacy tool subpackage, then inside of the legacy tools we differentiate the perl scripts. [...]

I agree. I just dealt with whatever was present at the time.

[...] So it's already mismatched IMO. So what do we need a "if perl" check for? It should be legacy tools or no legacy tools, right?

I think so. Would it hurt/make sense, if we made the --disable-perl be an alias for a new --disable-legacy (just for the backwards compatibility I mean). The --disable-perl wouldn't affect just the Perl tools but it still might be an acceptable compromise. What do you think?

So my issue is that we already have the legacy tool subpackage, then inside of the legacy tools we differentiate the perl scripts. [...]

I agree. I just dealt with whatever was present at the time.

Understood, I am not criticising what you did. It's just this "if perl" is confusing for everyone :-)

[...] So it's already mismatched IMO. So what do we need a "if perl" check for? It should be legacy tools or no legacy tools, right?

I think so. Would it hurt/make sense, if we made the --disable-perl be an alias for a new --disable-legacy (just for the backwards compatibility I mean). The --disable-perl wouldn't affect just the Perl tools but it still might be an acceptable compromise. What do you think?

Well, why don't we just remove the subpackage when we are ready to finally remove it? Why do we even need a flag? I get that right now it's broken, but I don't really see the purpose/need of it anyway. Thoughts?

Well, why don't we just remove the subpackage when we are ready to finally remove it? Why do we even need a flag? I get that right now it's broken, but I don't really see the purpose/need of it anyway. Thoughts?

I understand the desire to kill it with fire, but I think we need to have an option (disabled by default) to build with the subpackage for some foreseeable future. At least during RHDS 11.0 -> 11.1 cycle. We haven't got any feedback from customers (because RHDS 11.0 is not out yet), so we can't be over confident with the removal of the legacy tools. We need to have a smooth migration path not only for customers but for us too: we need to make sure that our tooling and automation works without legacy tools, and if not, have a kill switch to bring these tools back.

How about we have a --disable-scripts flag, and we can manage it that way? SUSE is a bit less hand tied here as we only just introduced 389, so we have shipped with --disable-perl meaning "disable legacy", but I tottaly get your support needs.

Then you can move the sh tools to that legacy pkg and remove it for a future release?

Well, why don't we just remove the subpackage when we are ready to finally remove it? Why do we even need a flag? I get that right now it's broken, but I don't really see the purpose/need of it anyway. Thoughts?

I understand the desire to kill it with fire, but I think we need to have an option (disabled by default) to build with the subpackage for some foreseeable future. At least during RHDS 11.0 -> 11.1 cycle. We haven't got any feedback from customers (because RHDS 11.0 is not out yet), so we can't be over confident with the removal of the legacy tools. We need to have a smooth migration path not only for customers but for us too: we need to make sure that our tooling and automation works without legacy tools, and if not, have a kill switch to bring these tools back.

I'm not saying we need to remove the subpackage yet (nor am I in a rush to do so), but I don't see why just removing the perl scripts from the legacy tools serves a purpose. That's all I was trying to say.

So I guess, what's actionable here? What state do we want this to look like?

So, the basic point we agreed upon is having a flag in the configure.ac that will allow/disallow legacy tools altogether. I'd call it --enable-legacy if no one objects. For the sake of backwards compatibility I would keep the --enable-perl which would comprise the actual Perl tools and which would be automatically disabled once one disables the legacy tools. I'm currently shuffling the lines within the files to meet this logic. Once we sufficiently tested with --disable-legacy and are confident with actual removal implications, we can just remove the respective conditional sections.

Seems reasonable to me :)

@mhonek Any further work here?

@mhonek any update? This should not be taking this long. Can you please rebase the PR so we can see where you are at and help you?

I've rebased (since there is no point in comparing with the previous patch) to. Please, look if it makes sense. And sorry for the delays...

It all looks good to me, can you check that defaults.inf that is emitted by default still has "Perl_enabled = no" and with legacy_on is "perl_enabled = yes"? This will affect lib389/tests for qe (and especially rh).

It all looks good to me, can you check that defaults.inf that is emitted by default still has "Perl_enabled = no" and with legacy_on is "perl_enabled = yes"? This will affect lib389/tests for qe (and especially rh).

LGTM as well (taking into account @firstyear's comment)

The perl_enabled option is generated as expected. Thanks for the review guys.

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3664

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.