Now that ports transitioned to git as well (and once the dust has settled), I would like us to remove SVN from OPTIONS_DEFAULT in the git port to reduce the number of dependencies pulled in when installing git. Feel free to close WONTFIX if this isn't wanted by the maintainer.
This seems reasonable to me. We ought to have a separate git-svn port again, but I agree there's now much less reason for the default port to have svn enabled.
(In reply to Ed Maste from comment #1) Or maybe a svn flavor, to go with the lite and tiny flavors?
(In reply to Steve Wills from comment #2) Or even a `full` flavor, with all options enabled. I agree subversion should be moved to off by default on main flavor.
I ended up creating the svn flavor. Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=64d5a3b23aca5e0da4ffb9430131f6fad3341106 commit 64d5a3b23aca5e0da4ffb9430131f6fad3341106 Author: Renato Botelho <garga@FreeBSD.org> AuthorDate: 2021-04-06 15:27:07 +0000 Commit: Renato Botelho <garga@FreeBSD.org> CommitDate: 2021-04-06 15:29:59 +0000 devel/git: Disable SVN and create flavor Ports tree moved to git. Disable SVN option by default on main port to reduce dependencies and create a new flavor "svn" that looks exactly how main port was before this change PR: 254719 Reported by: grembo Sponsored by: Rubicon Communications, LLC ("Netgate") devel/git/Makefile | 19 +++++++++++++------ devel/git/pkg-descr-svn (new) | 6 ++++++ 2 files changed, 19 insertions(+), 6 deletions(-)
Removing default options on a whim, or because *FreeBSD project* doesn't use SVN, is not very nice to users. This is the only package I would need to build locally now. These flavors are not mutually exclusive features but they are being treated as such for some reason. If we had sub-packages this might make more sense to me. ~ CVS is enabled but SVN is not? ~ If someone wants to reduce dependencies they are in a niche case of wanting to save space or build times or something, not something a general package user cares about. It's bad enough there is 'tiny' and 'lite' here. There's no obvious difference to me without digging into source code, again which a general package user doesn't care to do. The COMMENTS don't help as they just repeat the flavor name. Also OPTIONS_FILE usage appears to be a hack that needs to be fixed in Mk/ instead. It is not right for individual ports to roll their own options saving support. It's a flaw with FLAVORS that it doesn't work right already.
Turning off CVS and P4 support by default makes sense to me. Having a way users could get support for SVN, P4 and CVS without having to build would be nice too.
(In reply to Bryan Drewery from comment #6) > Removing default options on a whim, or because *FreeBSD project* > doesn't use SVN, is not very nice to users. This is the onl > package I would need to build locally now. Not being the maintainer, I suggested to remove svn from the default package, because, after LLVM moved away from subversion, FreeBSD was the only project I knew that still uses it (that's open source, I haven seen/used subversion commercially for almost a decade). > ~ CVS is enabled but SVN is not? ~ OpenBSD and NetBSD still use CVS. :) > If someone wants to reduce dependencies they are in a niche > case of wanting to save space or build times or something, > not something a general package user cares about. I don't dare to speculate about what "general package users" care about. To me, subversion is a niche case (and also was, when FreeBSD still used it). But one user's niche case is another user's hard requirement. Other operating system distributions (only checked Ubuntu and Debian) seem to package git-core and git-svn separately. With git ending up in soooo many places (jails, container, etc.), at some point keeping things relatively tidy stops being a niche case though. It's used a lot more in automation and infrastructure than subversion. Not only do the extra dependencies more than double the amount of disk space used, but they also add in another 30 packages which all need to be monitored and updated: apr: 1.7.0.1.6.1_1 db5: 5.3.28_7 gdbm: 1.19 glib: 2.66.7_1,1 gmp: 6.2.1 gnupg: 2.2.27 gnutls: 3.6.15 libassuan: 2.5.4 libedit: 3.1.20210216,1 libgcrypt: 1.9.2_1 libgpg-error: 1.42 libidn2: 2.3.0_1 libksba: 1.5.0 liblz4: 1.9.3,1 libtasn1: 4.16.0_1 libunistring: 0.9.10_1 nettle: 3.7.2_1 npth: 1.6 p11-kit: 0.23.22_1 p5-Term-ReadKey: 2.38_1 p5-subversion: 1.14.1 pcre: 8.44 pinentry: 1.1.1 pinentry-curses: 1.1.1 serf: 1.3.9_6 sqlite3: 3.34.1,1 subversion: 1.14.1 tpm-emulator: 0.7.4_2 trousers: 0.3.14_3 utf8proc: 2.6.1 many of them being ports that are notorious to require constant security updates. > It's bad enough there is 'tiny' and 'lite' here. There's no obvious > difference to me without digging into source code, again which a general > package user doesn't care to do. The COMMENTS don't help as they just > repeat the flavor name. One has curl (and therefore httpx support), the other doesn't. I agree that it would be nice to have non conflicting git ports that could be used in a plug and play fashion - e.g., devel/iocage would be totally fine with git-lite, but depending on git-lite is a non-starter, once someone needs "full git" (as every time you install it directly or as a dependency, iocage would get deinstalled). Now, enough lamenting, what could be done about this? Looking at the git port, it seems like turning on SVN does three things: 1. Add the git-svn man page 2. Add the git-svn executable (which is a perl script) 3. Add a ton of dependencies So, I think, the easiest solution is to create a slave port named git-svn, with git being the master port, that depends on the git port and brings in the dependencies and the missing two files. Maybe this could also be modeled on top of flavors somehow (with the git-svn flavor depending on non-flavored git and only bringing in a few extra files - no idea if this is viable though). P4 is basically the same (some scripts, and python - which is also used by contrib), CVS as well (a few more dependencies, a couple of more perl scripts). I'll play with this a bit and suggest a patch, assuming I can find the time necessary to do so.
@garga @bdrewery @swills I opened a code review that splits off git-svn, git-p4, and git-cvs as subports that depend on git (so they can be installed on top of each other). Not brilliant, but works. Would like to see the same with git-gui, so this could be installed optionally as well, but this first step might help to reduce Bryan's frustration. Differential: https://reviews.freebsd.org/D30238 Raw diff: https://reviews.freebsd.org/D30238?download=true
(In reply to Michael Gmelin from comment #9) https://reviews.freebsd.org/D30238 / https://reviews.freebsd.org/D32369 were committed in https://cgit.freebsd.org/ports/commit/devel/git?id=ff5ded75bcda28c580623504e01f5db8eb6be9cf: devel/git: Split into subpackages Removed CVS, GUI, PERFORCE and SUBVERSION options and also gui and svn FLAVORS, and create 4 new subports: devel/git-cvs devel/git-gui devel/git-p4 devel/git-svn All these packages depend of devel/git and install only additional files and manpages. This work is based on initial patch submitted by grembo@i at review D30238. PR: 251090 Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D32369