portsnap belated complaint?
rwmaillists at googlemail.com
Sat Aug 22 13:50:30 UTC 2020
On Fri, 21 Aug 2020 22:17:51 -0600
Gary Aitken wrote:
> On 8/21/20 12:11 PM, Polytropon wrote:
> >> ...
> >> Fetching 4 metadata patches... done.
> >> Applying metadata patches... done.
> >> Fetching 0 metadata files... done.
> >> Fetching 22 patches.
> >> (22/22) 100.00% done.
> >> done.
> >> Applying patches...
> >> done.
> >> Fetching 2 new ports or files... done.
> >> /usr/ports was not created by portsnap.
> >> You must run 'portsnap extract' before running 'portsnap update'.
> How can it apply patches if an extract hasn't been done and is needed?
> Does it knowingly, by default, apply patches to a tree it knows is
> "bad"? In this case, bad may simply mean installed at sysinstall time?
> Is that a known/documented behavior people rely on?
The patches are being applied to the compressed snapshot, not to the
The main three commands are
fetch - create or update the compressed snapshot from a remote server
extract - extract the entire snapshot over the ports tree and
initialize hidden metadata under the ports tree.
update - compare metadata files and extract parts of the snapshot that
have been updated
It's not hugely wrong to adopt a tree installed from a tarball. The
issue is that obsolete files that are outside of a port directory and
weren't installed by portsnap wont be deleted automatically. Usually
such files will be ignored, but there is a very small risk that they
might have an effect.
The original point of the tree from the installer is that it was the one
used to created the packages on the installation media. This meant that
it was safe to mix and match ports and packages provided you didn't
update anything, other than applying security packages.
More information about the freebsd-questions