Ports transitioned to git.

richardtoohey2 said:
For those of those not yet up to speed, will "portsnap fetch update" work or I need to do something different?
Click to expand...
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.
 
Zirias said:
portsnap is deprecated
Click to expand...

Then the handbook should be updated:

docs.freebsd.org

Chapter 4. Installing Applications: Packages and Ports

FreeBSD provides two complementary technologies for installing third-party software: the FreeBSD Ports Collection, for installing from source, and packages, for installing from pre-built binaries
docs.freebsd.org docs.freebsd.org

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?
 
_martin said:
I'll need to catch up on these svn to git migration changes.
Click to expand...
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.
 
Zirias said:
gitup is even a bit easier to use than portsnap
Click to expand...

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.)
 
jmos said:
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.
Click to expand...
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.

jmos said:
Your link tells me that git saves some disk space - but it seems to me that it was "usefull wasted" before
Click to expand...
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.

jmos said:
(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.)
Click to expand...
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.
 
Zirias said:
Ha, looking a bit deeper into this: pkg DOES use an index if present in the ports tree.
Click to expand...
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.

Zirias said:
make index will build it locally, which, of course, requires traversal again.
Click to expand...
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

_martin said:
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.
Click to expand...
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 :)
 
befreesd said:
… 24.5.3 Updating the Source and 4.5 Using the Ports Collection …
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top