git perl-less build?

[Petr Pisar]

On 2015-06-09, Vít Ondruch <vondruch at redhat.com> wrote:
> Unfortunately, this is wrong assumption. It comes quite natural that if
> I want to use git command, I can do "dnf install /usr/bin/git" and I
> don't care which package ships this command. And this scenario is broken
> now, since this will not install "full" git I expect.
>
You cannot have both of them. Either the subcommand is optional and
then installing /usr/bin/git cannot do the magic for you, or the
subcommand is not optional and then you will always get the subcommand
including all its dependencies.

> And as it turns out, it breaks also Ruby build [1], since it uses
> "BuildRequires: %{_bindir}/git", but the test suite later call "git
> submodule" command, which is not available anymore due to this split.
>
It breaks anything what expects that the subcommand works if git package
was installed. This is the omnipresent doom of expressing an API by
a package name. Once an API moves, reverese dependcies will break. IMHO
there is no way how to ensure this will not happen. Only rebuilding
everything and comparing before and after results. That's the reason why
these changes happen only in unreleased Fedora.

> I am wondering if there is some way out, for example git packages could
> have virtual provides such as git(add), git(submodule), git(rm),
> git(commit) and my package could then depend on the specific virtual
> provides, but I am not sure it is worth of the effort.
>
This is a solution. For example recent dnf does similar thing for DNF
plug-ins. However just introducing this schema doesn't fix anything. One
has to edit all other packages to use this new syntax. Otherwise it just
provides accaptable excuse for git maintaners about a new packaging
guideline that others do not conform to.

-- Petr