Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Aug 2020 15:28:35 +0200
From:      Lars Engels <lars.engels@0x20.net>
To:        Steve Wills <swills@freebsd.org>
Cc:        "ports@FreeBSD.org" <ports@freebsd.org>
Subject:   Re: [HEADS UP] Planned deprecation of portsnap
Message-ID:  <20200810132835.GN24022@e.0x20.net>
In-Reply-To: <b920d0e6-72d3-b37c-e57e-6d027292e8db@FreeBSD.org>
References:  <b920d0e6-72d3-b37c-e57e-6d027292e8db@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote:
> 
> We are planning to deprecate use of portsnap in ports.
> 
> The reasons are as follows (in no particular order):
> 
> * Portsnap doesn't support quarterly branches, even years after 
> quarterly branches were created and changed to the default for non-HEAD 
> packages.
> 
> * Portsnap doesn't seem to save disk space compared to svn or git, if 
> you count the metadata (stored in /var/db/portsnap by default) and you 
> do an apples-to-apples comparison of svn or git without history and 
> ignoring possible ZFS compression. That is, you use "svn export" or git 
> "clone --depth 1", you see this disk usage:
> 
>      342M    svnexport
>      426M    git
>      477M    portsnap
> 
> * Portsnap also doesn't work offline which git does. With git, you can 
> also easily add the history by running "git pull --unshallow"
> 
> * This migration away from portsnap fits well with the planned migration 
> to git.
> 
> * Also based on the patches we've seen in Bugzilla for some time, usage 
> of portsnap causes folks to too easily accidentally submit patches to 
> Bugzilla which don't apply easily.
> 
> * Since portsnap doesn't support quarterly branches, it often causes 
> users to build on the wrong branch or end up with mismatched packages. 
> That is, they install packages from quarterly via pkg, then want to 
> customize so run portsnap and build from head, which can cause problems, 
> as we often see. Even when this doesn't happen, it adds to 
> troubleshooting to verify that it didn't.
> 
> We are aware people have gotten used to portsnap, but believe:
> 
> * People should be able to easily use svnlite in base or git from pkgs. 
> (Very few people seem to actually use WITHOUT_SVNLITE).
> 
> * There is also the possibility of falling back to fetching a tar or zip 
> from https://cgit-beta.freebsd.org/ports/ although this does make 
> updating harder.
> 
> How it will be done, in order:
> 
> * Update poudriere to use svn by default. This is already done:
> 
>    https://github.com/freebsd/poudriere/pull/764
>  
> https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10
> 
> * Update docs not to mention portsnap. This is already in progress:
> 
>    https://reviews.freebsd.org/D25800
>    https://reviews.freebsd.org/D25801
>    https://reviews.freebsd.org/D25803
>    https://reviews.freebsd.org/D25805
>    https://reviews.freebsd.org/D25808
>    https://svnweb.freebsd.org/changeset/base/363798
> 
>    Many thanks to the folks who have worked and are working on this!
> 
> * Make WITHOUT_PORTSNAP default in base. Currently not certain when this 
> will happen. May not happen before 13.0, but hopefully it will.
> 
> * Eventually, portsnap servers will see low enough usage they can be 
> disabled.
> 
> We welcome any constructive feedback. All input would be heard, and if 
> the plans need to be amended, we will come back to you with the amended 
> plan in a couple of weeks. This process will take some time and 
> hopefully won't be too disruptive to anyone's usual workflow.
> 

I'm probably fine with this and I think that all of the (now) supported
methods have pros and cons.
To leverage the UX flaws of git and svn(lite) compared to portsnap
having a wrapper script around the two tools would be very appreciated.

Something like

# portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch extract
  The package devel/git does not seem to be installed, do you want to install it? (Y/n) _

With sane defaults, so you can just run portsnap fetch extract like
you're used to and this
downloads the latest ports tree to /usr/ports using base svnlite(1).

While we're here: Can we please have a separate user that is used to
checkout the tree? 

Lars


P.S.: Please DO NOT name the wrapper portsnap-ng. :-)



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