Add --spec and --srpm no-op arguments to the builddep plugin

[dcantrell]

Under dnf4 the builddep command accepted the --spec or --srpm argument (mutually exclusive) to tell dnf what the input to the command was. With dnf5 the command is more intelligent and the arguments are not required. However, if you are bringing a script over from an existing system and you have --spec or --srpm for the builddep dnf command, you will get this error:

Unknown argument "--spec" for command "builddep". Add "--help" for more information about the arguments.

This patch addes the --spec and --srpm arguments to the builddep command, but they are ignored. They exist for backwards compatibility.

Fixes: #799

[j-mracek]

Be honest I am not sure whether dummy options are the right solution. First of all we usually adds such options to aliases configuration file.

There is another problem - those option are ignored therefore script will not fail but does not provide required functionality. If I am not mistaken it is valid for --srpm option.

[pmatilai]

There is another problem - those option are ignored therefore script will not fail but does not provide required functionality. If I am not mistaken it is valid for --srpm option.

Hmm, what do you mean by that? I only took a cursory glance at the code + quick test but it looks to me like both specs and src.rpms are processed as expected in dnf5 version, without the need for an explicit --spec or --srpm.

[m-blaha]

I would prefer to have fully functional options instead of the dummy ones.
Here the dnf5 is not more intelligent than the dnf4 (they both do automatic decision based on the file name) - the options in question were added on purpose to allow to process files with non-standard extensions. Here is the original request - https://bugzilla.redhat.com/show_bug.cgi?id=1241135 (although I'm not sure how much valid the use case still is).

Thinking about unknown options - wouldn't be better solution to just ignore them all (with some warning to the user)? The only trouble might be with options with values set without = sign. For example in dnf install --unknown-option-with-value option-value pkg-spec command it's not clear whether option-value should be handled as value of unknown-option-with-value or as a package spec to install. Unfortunately this syntax (without = sign) is supported in dnf5 commandline arguments parser for compatibility reasons.

[pmatilai]

the options in question were added on purpose to allow to process files with non-standard extensions

Oh, I had missed that. In that case I agree, dummy options that don't do what the original did are problematic.

If explicit format is required, maybe it'd make more sense to have them take an argument instead, ie '--srpm fubar.r.p.m --spec myspec.txt'. But then I don't really understand the need for such functionality, if you name your spec something else than .spec you're just shooting your own foot...

[dcantrell]

OK, so my understanding now is that we should have the same functionality as dnf4 had. I would vote for implementing the options in the same way as they already exist, even if that is not really ideal. We could add additional option handling that is "cleaner" but I think we should support the existing options as they work.

I will redo the PR.