On 4.6.2015 09:56, Haïkel wrote:
2015-06-04 9:34 GMT+02:00 Petr Stodulka <pstodulk(a)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(a)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.
Yes and documentation is now part of git-core subpackage.
git(-core)-doc
could provides option to install just doc files without set of other
packages. That sounds more clear then have doc files available only with
set of perl's packages with git package.
End-users who will use the doc, will end up installing the git
package
Regards,
H.
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct