<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 3.6.2015 15:35, Todd Zullinger
      wrote:<br>
    </div>
    <blockquote cite="mid:20150603133518.GM22129@zaya.teonanacatl.net"
      type="cite">Josh Boyer wrote:
      <br>
      <blockquote type="cite">On Wed, Jun 3, 2015 at 9:19 AM, Petr
        Stodulka <a class="moz-txt-link-rfc2396E" href="mailto:pstodulk@redhat.com">&lt;pstodulk@redhat.com&gt;</a> wrote:
        <br>
        <blockquote type="cite">On 3.6.2015 13:56, Pierre-Yves Chibon
          wrote:
          <br>
        </blockquote>
      </blockquote>
      [...]
      <br>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">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.
            <br>
            <br>
            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.
            <br>
          </blockquote>
        </blockquote>
      </blockquote>
      [...]
      <br>
      <blockquote type="cite">
        <blockquote type="cite">Thank you Pierre, that sounds
          reasonably. We could create packages *git-core* &amp;
          *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?
          <br>
        </blockquote>
        <br>
        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.
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      ¹ Here is the current list of subpackages from master:
      <br>
      <br>
         emacs-git
      <br>
         emacs-git-el
      <br>
         git-all
      <br>
         git-cvs
      <br>
         git-daemon
      <br>
         git-email
      <br>
         git-gui
      <br>
         gitk
      <br>
         git-p4
      <br>
         git-svn
      <br>
         gitweb
      <br>
         perl-Git
      <br>
         perl-Git-SVN
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    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.<br>
  </body>
</html>