Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Aug 2005 14:16:09 -0700
From:      Colin Percival <cperciva@freebsd.org>
To:        Peter van Dijk <peter@dataloss.nl>
Cc:        freebsd-arch@freebsd.org
Subject:   re: portsnap base thought
Message-ID:  <4310D819.9080903@freebsd.org>

next in thread | raw e-mail | index | archive | help
Peter van Dijk wrote:
> portsnap requires that the /usr/ports on a machine was created with
> portsnap extract, before it will allow you to portsnap update.
> 
> Suggestion: make the portstree as delivered in 6.0-RELEASE (on the CD
> etc.) compatible with portsnap extract, so people can use portsnap
> from a base CD install without having to fetch the portstree through
> portsnap first. I do realise this might bloat the CD image by about
> 50 megabytes (because of /var/db/portsnap) but I think it's worth it.

There are two quite separate issues here:
1. When "portsnap fetch" is first run, portsnap needs to download a
compressed snapshot of the entire tree (roughly 35MB).
2. If you try to run "portsnap update" against a ports tree which was
not created with "portsnap extract", portsnap will refuse to run because
it doesn't know which files in the ports tree need to be updated.

The solution to the first problem is to ship a copy of /var/db/portsnap
on the release images; this would add roughly 35MB to the release size,
but it would also allow 28MB to be reclaimed by not shipping ports.tgz
(and instead extracting it using portsnap).

The solution to the second problem is to ship a copy of the ports tree
which contains an appropriate /usr/ports/.portsnap.INDEX file; this would
add roughly 600kB.

Given that portsnap currently only has about 1500-2000 users (it's hard to
get an accurate estimate since people tend not to update their ports trees
as often during the freeze, but I'm fairly confident the number is in that
range) it doesn't seem reasonable to make major changes to how releases
are done yet; but assuming the usage of portsnap increases significantly
over the next year, this is certainly something to consider for 7.0-R.

Colin Percival



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