Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Jan 2013 00:57:17 -0800
From:      'Jeremy Chadwick' <jdc@koitsu.org>
To:        Dewayne <dewayne.geraghty@heuristicsystems.com.au>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: svn - but smaller?
Message-ID:  <20130124085717.GA26673@icarus.home.lan>
In-Reply-To: <E10EBB96DCC143BE8F14FD2982AD84B7@white>
References:  <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <E10EBB96DCC143BE8F14FD2982AD84B7@white>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 24, 2013 at 06:34:33PM +1100, Dewayne wrote:
> The objective is to return to a base build of FreeBSD that performs
> the expected task of being able to pull source, without having to
> acquire a port.  Regardless of our individual solutions/workarounds,
> the task is to pull and maintain source.
> 
> Is the discussion going to result in something like svn-lite that
> enters into the /usr/src/contrib along with the responsibilities
> associated with maintaining it?  And then we need to take into
> consideration of being overwriting the "base svn" with a full svn
> package, if required by the user/admin.

Regarding your "svn-lite" theory of having that added to src/contrib/,
let me introduce you to Subversion's actual dependencies, and I'll
explain why these would have to remain enabled (for a "base system"
Subversion) as well:

* SQLite3 (used for bits/pieces in .svn/ directories)
  -- License: http://www.sqlite.org/copyright.html
  -- Not in the base system

* APR (used for HTTP fetching (not necessarily HTTPS))
  -- License: http://www.apache.org/licenses/LICENSE-2.0.html
  -- Not in the base system

* Expat 2.x (XML parsing/generation library
  -- License: http://en.wikipedia.org/wiki/MIT_License
  -- Not in the base system

* Neon or Serf (used for HTTPS fetching)
  -- Neon license: http://www.gnu.org/copyleft/lgpl.html
  -- Serf license: http://www.apache.org/licenses/LICENSE-2.0
  -- Neither are in the base system
  -- Serf supposedly has some kind of wonky/weird bugs on FreeBSD; I
  remember reading about these on the mailing lists or in PRs, combined
  with some statement about how newer Subversion uses Serf exclusively?

* gettext and libintl (used for character set support)
  -- gettext license: GPL (not sure what version)
  -- libintl license: LGPL (not sure what version)
  -- Neither are in the base system

* libiconv (used for character set conversion)
  -- License: LGPL (not sure what version)
  -- Not in the base system

Why would all of these third-party bits be required?  Keep reading.

> The issue involves policy decisions along with ongoing support load,
> rather than just a good technical solution; which as we've seen in
> earlier discussions, is sorely needed by the folks doing the
> development/maintenance.
> 
> In the meantime, ftp isn't really workable for ongoing updates, and
> rsync is GPL'ed and can't be in the base system.
> 
> I build svn from ports with all options off except for:
> ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn
> program. Suites me but doesn't address the underlying problem - and I
> don't think that the plan is to make FreeBSD dependent upon the ports
> system (for subversion)

Though your OPTIONS recommendations work for you, they do not work for
everyone.  Some people sit behind firewalls where HTTP or HTTPS are the
only viable means (native SVN or SVN+SSH will not work for them).  Thus,
any kind of "base system svn-lite" would need to offer all of these
out-of-the-box, hence the above dependency list becoming mandatory.
src.conf WITHOUT_x knobs could turn some of these off, but they'd still
have to become part of src/contrib/.

FreeBSD for many years has been trying to remove "non-BSD-compatible"
software from the base system.  I can't find the statement but the move
towards LLVM/Clang is partially driven by this, as well as the push to
move from GNU grep to bsdgrep.

Now, review the above dependencies and ask yourself the likelihood of
all of those being brought into src/ any where.  I imagine given its
large dependency count on software that has "non-BSD-compatible"
licenses, that statement likely proves true.  I believe there was also a
statement made in passing on the mailing lists not too long ago
mentioning that Subversion would never be brought into the base system
for that reason.  I would love (LOVE!) to find out there are plans to
move it into the base system, but I can't see how given the above.

As for your last line:

FreeBSD is already dependent upon Subversion.  This has been the case
for quite some time, but has only recently (as an indirect result of the
security incident) become forced upon users/administrators of FreeBSD.
The entire project is presently managed/maintained under Subversion.
The Handbook now documents that if you want to pull down src/ you need
to install Subversion.  If you want to pull down ports/ you can use
portsnap and waste lots of /var space, hoping that the portsnap mirrors
are up to date, and a bunch of other hullabaloo... or you could just use
Subversion and be done with it.

There is no more cvsup.  There is no more csup.  There is no more cvs.
There is only Subversion ("there is only Zuul...").  I do not want to
talk about the whole security incident situation because it's another
topic that makes me quite volatile.

Also, just as a footnote point to readers: please do not bring up
svnsup.  Until it's stated by some official FreeBSD person that
"{committers} are actively working on this and bringing it into the base
system so people can get src/ports without installing
ports/devel/subversion", it's not pragmatic to mention it as a
*solution*.

-- 
| Jeremy Chadwick                                   jdc@koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130124085717.GA26673>