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.
|
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct