[HEADS UP] Planned deprecation of portsnap
Lars Engels
lars.engels at 0x20.net
Mon Aug 10 13:28:45 UTC 2020
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. :-)
More information about the freebsd-ports
mailing list