On 2015-06-09, Vít Ondruch <vondruch(a)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