Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Aug 2020 08:22:15 +0200
From:      Polytropon <>
To:        Gary Aitken <>
Cc:        RW <>,,
Subject:   Re: portsnap belated complaint?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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 core "problem" is that portsnap can only operate on trees
that originate from a portsnap run. It cannot use ports trees
installed from scratch (i. e., from the installation medium),
or on such obtained via SVN.

As explained in "man 8 portsnap", the operations "fetch", "extract"
and "update" require a certain order and have "limited" results:
"fetch" only fetches the snapshot, "extract" puts it into place,
and "update" alters a ports tree according to a previously
"fetch"ed snapshot.

The initial observation leads me to believe that the ports tree
that has been tried to update was not written by portsnap, which
is also suggested by its error message.

> > Everything you see matches the expected behaviour according to
> > your problem description:
> > 
> >> I believe the ports tree was generated when the OS was installed,
> >> [...]
> >> # portsnap fetch
> >> [...]
> >> # portsnap fetch update   <mistakenly left fetch in the cmd>
> >> [...]
> >> /usr/ports was not created by portsnap.
> > 
> > Whatever you have fetched, it was never extracted; what is still
> > present in /usr/ports is not "compatible" with portsnap
> ...
> I'll assume it's all the result of installing ports with a new sysinstall
> months ago; I thought I had extracted and updated and used it already.

Exactly my impression.

A ports tree that comes from bsdinstall is not something that
portsnap can operate on.

> Why doesn't the ports install done at sysinstall time not do the equivalent
> of a fetch & extract?  Would doing so be incompatible with anything else?

Because at installation time, the ports tree that was current
at the point of RELEASE is shipped on the installation medium.
This is different from what portsnap expects, that's why the
suggestion to _if_ you want to use portsnap, always start with
a fresh snapshot, removing any /usr/ports that might already
be there ("might", because the ports tree is optional and can
be omitted during installation).

> (I think this is the third time I've gotten caught by this <rant>stupid</rant>
> behavior.  I guess it's a moot point since portsnap is going away.)

THe same applies when you use SVN to get "more fine grained"
updates - you also need to start with a fresh copy created
by SVN. Those methods are not interoperable. :-)

> Does installing the ports tree when the system is installed and then
> using portsnap count as mixing tools?

Yes. The tree installed by bsdinstall is not usable for any
further use with portsnap.

> If so, it should be noted when the
> option is presented at install time that if you are planning on updating the
> ports tree, there's no point in installing it.

That is absolutely understandable. As I've mentioned, any
updating method, be it portsnap or svn, requires that you
start with a clean new snapshot or checkout of /usr/ports.
Installing the ports tree with bsdinstall only makes sense
if you want to keep using _that_ version of the ports tree
(i. e., the version of the tree that was current when the
FreeBSD version was released).

> Will this same behavior exist with the switch to git?

I almost would think so. The suggestion will probably be:
Remove /usr/ports, and then initialize the ports tree from
scratch using git...

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>