Ports transitioned to git.

For those of those not yet up to speed, will "portsnap fetch update" work or I need to do something different?
portsnap is deprecated, but AFAIK, this doesn't relate directly to git. I don't know for how long it will still work.

My recommendation would be to use net/gitup instead, givig very similar functionality, but directly accessing a git repository for it.
 
portsnap is deprecated

Then the handbook should be updated:


Portsnap also comes with the base system, and there's no hint to that in the manpage or "--help" option. Shure that is official & written in stone - and not a dream of some fans of git?
 
It seems my FreeBSD knowledge is getting stale, I'll need to catch up on these svn to git migration changes.
 
I'll need to catch up on these svn to git migration changes.
Not much to catch up on, the ports tree is the last to get migrated. Source and docs have been migrated already. Source for releng/11.4 and releng/12.2 can still be found on subversion, from releng/13.0 onward it's only available through git. But this really only impacts people that use the source to update/upgrade, nothing's changed for freebsd-update(8) users.
 
SirDice I don't use git too often and when I do I always have to google how to set up the repository. I need to get familiar with the git, how to summarize the different commits, etc.
I was lazy to do so, I guess now I have an extra push and motivation to do so. :)
I always used cvs and later svn. I do like that approach and prefer it to freebsd-update(8). It's only a personal preference, nothing more behind it.
 
  • Like
Reactions: PMc
It wasn't updated when I checked yesterday or this morning when I checked first thing:

root@bakemono:/ # portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
Ports tree is already up to date.


It was updated in time to get the fixed version of security/nettle 3-30-21 after I contacted the Maintainer. That's the last update I got or expect till the change is finalized.
 
gitup is even a bit easier to use than portsnap

pkg version -vl '<' took a blink of an eye. Now i tested a gitup ports, and that pkg command takes now ~40 seconds till the ~200 packages are listed that the ports tree is newer than the quarterly binary packages I've got installed.

Your link tells me that git saves some disk space - but it seems to me that it was "usefull wasted" before ;) Is there a better (faster) command now to get a list of the updateable ports? "/var/db/pkg/repo-FreeBSD.sqlite" seems no longer to be modified, so directly asking that database is also not an option anymore…

(No one asked, but: I don't think that anyone would not contribute because there's svn and not git (that was named as the reason for this switch). Git is just the next cool must have to play with. It has zero benefit to me, but is a additional burden to deal with.)
 
pkg version -vl '<' took a blink of an eye. Now i tested a gitup ports, and that pkg command takes now ~40 seconds till the ~200 packages are listed that the ports tree is newer than the quarterly binary packages I've got installed.
Both tools give you a plain tree of files. With portsnap, you have metadata in /var/db, with git in a single subdirectory in /usr/ports. This doesn't change anything about the speed of traversal on the filesystem level.

Your link tells me that git saves some disk space - but it seems to me that it was "usefull wasted" before
No. No other tool except portsnap itself ever uses portsnap's metadata.

edit: Ha, looking a bit deeper into this: pkg DOES use an index if present in the ports tree. That's not portsnap's metadata, but portsnap fetches it together with the snapshots. You can fetch it yourself with make fetchindex. Drawback: could be slightly out of date, similar to the snapshots portsnap fetches. But at least only a few hours, while porsnap snapshots can be a few days old.

make index will build it locally, which, of course, requires traversal again.

(No one asked, but: I don't think that anyone would not contribute because there's svn and not git (that was named as the reason for this switch). Git is just the next cool must have to play with. It has zero benefit to me, but is a additional burden to deal with.)
I get it doesn't have any value for YOU. Well, bad luck, but the rest is utter nonsense.
 
When you first run # portsnap fetch extract the snpshot it downloads is approximately 76MB in size, possibly one or two larger. I didn't pay that close attention to it, having seen it in the past, but will be sure to take note next laptop I build.

Very soon.
 
Ha, looking a bit deeper into this: pkg DOES use an index if present in the ports tree.
Yes, that's why I always explicitly call pkg version -vR or pkg version -vI because the local INDEX file may or may not be up to date and this could skew the results.

Code:
     -I [index, --index [index]]
                 Use index file for determining if a package is out of date.
                 If no index file name is specified, uses the default index
                 file.  This is the default, if the index file exists.
Code:
     -R, --remote
                 Use repository catalogue for determining if a package is out
                 of date.  This is the default if neither the ports index nor
                 the ports tree exists.

make index will build it locally, which, of course, requires traversal again.
I prefer make index because it also takes my DEFAULT_VERSIONS settings into account. A make fetchindex will get a remote INDEX that uses the standard defaults.
I use this to update my ports tree:
Code:
cd /usr/ports && git pull && make index

I always used cvs and later svn. I do like that approach and prefer it to freebsd-update(8). It's only a personal preference, nothing more behind it.
If you're already familiar with CVS and SVN then GIT shouldn't be too difficult to understand. Some commands are slightly different but they all serve the same or a similar purpose.
 
WARNING: the cgit-beta ports tree is NOT stable!

There is currently no ports tree visible on the cgit server. As was suggested here on the forums, one can use the cgit-beta which does provide a ports tree.
If you do so (to test your local update scripts, like I am doing currently), there may be surprizes.

Shorthand: when you see "forced update" during fetch, the upstream may have changed in unexpected ways (as obviousely people are also testing there ;) ).
 
Yes, rewriting history is perfectly possible with git and the single worst no-no for anything public, for reasons ;) Of course, on a beta testbed, you might have to expect such things :)
 
Both links are from an outdated edition of the Handbook.

Documentation in general

Outdated links are very frequently seen (not your fault).

Folks, please habitually:
  1. page down to the foot of the page
  2. click Home
  3. if there appears a modification date and a revision, with reference to a commit, you're in an outdated document
  4. if you're in an outdated document, page down to the foot of the page
  5. click documentation then (e.g.) Handbook.
As far as I can tell: with current editions of documentation such as the Handbook, there's no modification date at the head of each chapter.

I do like documents to be dated but in this case, it's paradoxically helpful to be without a date because it probably signifies that it's up-to-date.



Ports in the FreeBSD Handbook

At a glance, the current edition of the Handbook is similarly non-prepared for completion of the transition.

I'll make a separate post with an outline of (or link to) what's probably required.
 
Back
Top