Date: Sun, 16 Dec 2012 16:51:48 +0100 From: David Demelier <demelier.david@gmail.com> To: freebsd-ports@freebsd.org Subject: Re: Let's talk about subversion/svn Message-ID: <50CDEE14.2040501@gmail.com> In-Reply-To: <20121119071607.GA58307@icarus.home.lan> References: <20121119071607.GA58307@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19/11/2012 08:16, Jeremy Chadwick wrote: > Given the incessant focus on everything using Subversion now (please do > not get me started, it will be like arguing with a brick wall), I'd like > to know what the plan is for minimising the number of dependencies. > > The present subversion **package** on the official FTP servers is for > subversion-1.7.6: > > root@icarus:~ # ftp ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/ > ... > ftp> dir subversion*.tbz > 229 Entering Extended Passive Mode (|||10279|). > 150 Here comes the directory listing. > lrwxr-xr-x 1 967 100 32 Oct 14 14:53 subversion-java.tbz -> ../All/subversion-java-1.7.6.tbz > lrwxr-xr-x 1 967 100 27 Oct 13 13:24 subversion.tbz -> ../All/subversion-1.7.6.tbz > lrwxr-xr-x 1 967 100 28 Oct 14 01:54 subversion16.tbz -> ../All/subversion-1.6.18.tbz > 226 Directory send OK. > > And this is partially what it pulls down dependency-wise: > > root@icarus:~ # pkg_add -r -n subversion > Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz... Done. > Package dependency sqlite3-3.7.14.1 for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found! > Package dependency gdbm-1.9.1 for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found! > Package dependency db42-4.2.52_5 for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found! > Package dependency neon29-0.29.6_4 for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found! > > I say partially because due to use of -n, some of those packages weren't > downloaded, thus the recursive dependency nature is lost (I consider > this mostly a bug with -n when used with a remote package, but it could > also be deemed a feature). > > However, GDBM and Oracle/Sleepycat DB aren't (by default) enabled > in 1.7.7 which is what's in ports currently: > > root@icarus:/usr/ports/devel/subversion # make run-depends-list > /usr/ports/databases/sqlite3 > /usr/ports/devel/apr1 > /usr/ports/devel/gettext > /usr/ports/textproc/expat2 > /usr/ports/www/neon29 > > So GDBM and Oracle/Sleepycat DB are now disabled by default (good!), > but now we have the following (and I will describe each of them for > readers so they know what they're for): > > - SQLite -- which I believe is used for data storage for commits/etc. > and tends to work well for that, so I'm okay with it. > - gettext -- needed for NLS, which I've learned to accept although I'd > rather everything today just use UTF-8 universally (idealistic me). > However, there are many people who are heavy WITHOUT_NLS advocates, > and I used to be one, so they should be honoured (IMO). > - APR -- have yet to figure this out. All I can think of is "svn is > an Apache project and we like injecting all our crap into everything, > so enjoy!". > - expat2 -- XML parsing library, which I also have yet to figure out > the need for. What VCS uses XML and why? Is this really *needed*? > - neon -- OPTIONS description labels this as "WebDAV/DAV support", > but in reality what this provides that's most important is HTTPS/SSL > support. I found this out the hard way when building svn for a > customer 4-5 months ago. NEON_DESC should really become this: > > NEON_DESC=WebDAV/Delta-V access module + HTTPS/SSL support > > I want people reading this to remember olden days, because it seems > we've taken a step backwards when it comes to applying minimalistic > approaches and KISS principle. I want people to remember the days of > this command: > > pkg_add -r cvsup-without-gui > > And how it had a dependency on ezm3 (Modula-3 language), which its > author insisted was needed "because cvsup's design needed M3 for speed" > (I'd have to dig up his exact words). This utter nonsense was debunked > when csup -- written purely in C -- was introduced into the base system. > I remember that day, and it was one of the happiest moments I had using > FreeBSD. Yes really. All of my co-workers at the time who used FreeBSD > rejoiced as well. > > I understand everyone uses svn differently, but there *needs* to be a > package (or stub port) that is minimal, i.e. "install this to use svn on > FreeBSD if you want to check out src and ports and other stuff"[1], that > has absolutely no fluff in it other than what's needed, and I am not > sure if the above defaults meet that requirement (thus possibly a > stub-port would be good). Possibly that can be accomplished by someone > updating the existing subversion.tbz package on the servers to 1.7.7? > Not sure. > > I also know FREEBSD_TEMPLATE is absolutely needed (failure to include > that will result in weird breakage, which I've seen posts complaining > about on the lists in the past). > > There is STATIC, which would be great for solving this (if you ask me), > but if I remember right the port maintainer stated sometime in the past > that he had concerns over this option given "security implications", > e.g. if SQLite, etc. had security holes in them and thus had to be > updated, a static build wouldn't be able to deal with that, but that's > just a bunch of hogwash (I can explain why in detail if wanted). So I > doubt we'll see something like subversion-static.tbz anytime soon. > > So what's the point of my Email? > > I want to find out what is being done by the FreeBSD folks (that means > Project members and Committers alike) to deal with this migration from > the end-user perspective. The Project has effectively destroyed > csup/cvsup in different ways, especially over the past 2 days (I love > seeing all CVS commits now done as user "svnexp" and the cvsweb.cgi > interface is 100% broken -- thanks! Nobody used this functionality > anyway, right?), so for me svn is the only choice[1]. > > Finally: for those wanting svn in the base system, good luck. I'm sure > licensing issues will be the main reason this can't happen. This just > circles back to my age-old argument about how the "base system" concept > on FreeBSD needs to be nuked, and that all "base system" software should > actually just be ports/packages and can be updated/maintained in that > same fashion (but obviously with much more scrutiny). There's no > technical reason this can't be done, only social reasons. For how this > is done properly, see Debian. > > I look forward to responses, but I can assure you I will respond very > little; I tend to be argumentative (case in point) and could battle this > all day and night, but more importantly, the work/effort here is not my > responsibility -- it is the responsibility of those who have deprecated > something that was minimal and "just worked out-of-the-box". > > > [1]: Regarding ports and "use portsnap": have no problem with portsnap, > but it doesn't work for my workflow/model. I absolutely need to see > things in more real-time fashion than "when a portsnap mirror decides to > update its snapshot from the master" (could be hours, could be days, who > knows -- and we have seen occasions of these delays happen already, and > not just recently). I used csup (and when providing diffs for PRs, cvs > itself) exclusively for ports and src, and I will therefore use svn for > the same purpose. Not for debate. :-) > We should write a snup tool similar to csup, a bootstrap tool that depends on nothing and can fetch both src/ ports/ and doc/ repositories with branches support. Cheers,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50CDEE14.2040501>