On 3.6.2015 15:35, Todd Zullinger wrote:
Josh Boyer wrote:
On Wed, Jun 3, 2015 at 9:19 AM, Petr Stodulka <pstodulk@redhat.com> wrote:
On 3.6.2015 13:56, Pierre-Yves Chibon wrote:
[...]
What about adopting something similar to what has been done for the R package, There is R-core, R-java R-devel and R. If you yum/dnf install R you get all of them and you can install either one independently.

So in this case, we could have git-core, git-perl, git-foo and yum/dnf install git would provides the full experience, while the atomic folks rely on git-core instead.
[...]
Thank you Pierre, that sounds reasonably. We could create packages *git-core* & *git-perl* sub-packages and both required inside original *git* package.  So user will be able to use still same functionality as usually without troubles, even after upgrade (doesn't count upstream changes).  And Atomic will use *git-core* package. Are you OK with this solution Colin?

This is somewhat funny, since we already _had_ git-core long ago for this very reason, and it was consolidated into a single git package.  History repeats itself.

Indeed.  We now have a git-all metapackage which pulls in all of the git subpackages, which is a lot¹.  Many of the subpackages are only useful for integration with other SCM systems, and that is certainly a good reason to have them not pulled in by default.

I do think that the default git package should continue to pull in the few core parts which rely on perl.  They might not be used by folks wanting a very minimal build, but they are quite commonly used by plenty of git users.

I think in addition to git-all which pulls in everything, a git-minimal (or git-core, if we want to repeat history) would be better than stripping the perl-dependencies from the default git install.

¹ Here is the current list of subpackages from master:

   emacs-git
   emacs-git-el
   git-all
   git-cvs
   git-daemon
   git-email
   git-gui
   gitk
   git-p4
   git-svn
   gitweb
   perl-Git
   perl-Git-SVN



OK, packages are split. Todd, can you check description texts and peculiarly change it if you found mistakes or better description you devise? I think about separate package git-core-doc (or git-doc, which will contains all doc files of git-core and git). Doc files of other subpackages could be kept without moving.