On 4.6.2015 09:56, Haïkel wrote:
2015-06-04 9:34 GMT+02:00 Petr Stodulka <pstodulk@xxxxxxxxxx>:
On 3.6.2015 15:35, Todd Zullinger wrote:
Josh Boyer wrote:
On Wed, Jun 3, 2015 at 9:19 AM, Petr Stodulka <pstodulk@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
