git perl-less build?

[Haïkel]

2015-06-04 9:34 GMT+02:00 Petr Stodulka <pstodulk at redhat.com>:
>
>
> On 3.6.2015 15:35, Todd Zullinger wrote:
>
> Josh Boyer wrote:
>
> On Wed, Jun 3, 2015 at 9:19 AM, Petr Stodulka <pstodulk at 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.
>

I may be wrong but I don't see the point in splitting the doc too.
People needing the git-core subpackages to save space are likely not
to install documentation.
End-users who will use the doc, will end up installing the git package

Regards,
H.

> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct