I gather portsnap has been deprecated and docs updated recently, however that has left some confusing bits: 1) Under https://docs.freebsd.org/en/books/handbook/ports/#ports-using, section 4.5.1: - "use one of the following methods to install it", but then only a single method (git) follows. 2) There is no instruction on what users who previously used portsnap or svn should do to convert to the newly supported git method. If it is as simple as blow away /usr/ports and check out via git that should be spelled out in a "migrating" section. 3) Perhaps a doc bug, perhaps a feature request: `pkg` defaults to quarterly branches, but does not seem to output which quarterly branch it is on. See example pkg -d output below. git seems to need a specific year + quarter (e.g. 2023Q2) tag. I'm not seeing a simple programatic way to keep the two in sync. - Maybe the git repo could have a tag "quarterly" like packages do that is moved forward once a quarter so the checkout can always just be of quarterly? - Maybe pkg can emit the quarter it is tracking (e.g. new command `pkg quarter`), ideally in the same format that git needs it (e.g. "git clone https://git.FreeBSD.org/ports.git -b `pkg quarter` /usr/ports" would work). - Maybe `pkg update` could have an option in the config file of "keep ports in sync" where it spawns an update to the ports tree if a quarterly boundary is crossed? - Maybe the daily/weekly/monthly periodic could have a new option of "keep ports and packages in sync" where the periodic script automatically updates the ports tree to match the pkg quarter. Use case: I prefer to install from packages, but from time to time I need to build a single bit of software from ports either because there is no package or because I need to customize a build time option. I suspect there are many like me, and today we have to manage two update methods and hope to keep the trees in sync. With the new quarterly thing it should be much easier for software to just do the right thing and not have humans have to run around and remember this stuff. Output below, which quarter is it updating to? I dunno! (From FreeBSD 13.2-RELEASE with pkg-1.19.2.) # pkg -d update DBG(1)[6448]> pkg initialized Updating FreeBSD repository catalogue... DBG(1)[6448]> PkgRepo: verifying update for FreeBSD DBG(1)[6448]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' DBG(1)[6448]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/meta.conf DBG(1)[6448]> opening libfetch fetcher DBG(1)[6448]> Fetch > libfetch: connecting DBG(1)[6448]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/meta.conf with opts "i" DBG(1)[6448]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/packagesite.pkg DBG(1)[6448]> opening libfetch fetcher DBG(1)[6448]> Fetch > libfetch: connecting DBG(1)[6448]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.pkg with opts "i" DBG(1)[6448]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/packagesite.txz DBG(1)[6448]> opening libfetch fetcher DBG(1)[6448]> Fetch > libfetch: connecting DBG(1)[6448]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.txz with opts "i" FreeBSD repository is up to date. All repositories are up to date.
(In reply to Leo Bicknell from comment #0) > … - "use one of the following methods to install it", but then only a > single method (git) follows. … Partly blocked by bug 255323, >> FreeBSD Handbook: document gitup An email to developers@ on 2023-05-07 began: > gitup and GoT (Game of Trees) in 14 > > <https://www.freshports.org/net/gitup> | <https://github.com/johnmehr/gitup> > > <https://www.freshports.org/devel/got> | <https://gameoftrees.org/> > > If not in 14.0, then might we have one or both in 14.1? > > For what it's worth, I lean towards including both in 14.0. It'll spark > less debate, long term, than including neither. … Thirty-seven responses, which I'll not attempt to abstract (in any case, it's a private list). Without reference to any response there: my gut feeling is that neither gitup nor GoT will be in 14.0-RELEASE.
(In reply to Leo Bicknell from comment #0) > 2) There is no instruction on what users who previously used portsnap or > svn should do to convert to the newly supported git method. If it is as > simple as blow away /usr/ports and check out via git that should be > spelled out in a "migrating" section. +1 to spelling out i.e. clear direction/orientation, however I'm giving no thought to an additional section. A sidebar search for Git includes: Using Git - currently at A.2 in Appendix A, <https://docs.freebsd.org/en/books/handbook/mirrors/#git>.
(In reply to Leo Bicknell from comment #0) > 3) Perhaps a doc bug, perhaps a feature request: `pkg` defaults to > quarterly branches, but does not seem to output which quarterly branch > it is on. See example pkg -d output below. git seems to need a specific > year + quarter (e.g. 2023Q2) tag. I'm not seeing a simple programatic way > to keep the two in sync. … <https://wiki.freebsd.org/Ports> has many subpages (the multi-line box near the foot of the page), including: - <https://wiki.freebsd.org/Ports/QuarterlyBranch> Six revisions by me in recent weeks. If you can take a fresh look at the wiki page (without the FreeBSD Handbook as context or comparison), does the page help to demystify things?
(In reply to Graham Perrin ◐ from comment #3) > Six revisions by me in recent weeks. If you can take a fresh look at the wiki page > (without the FreeBSD Handbook as context or comparison), does the page help to > demystify things? I think I understand it well enough, but my opinion is that the combination of how packages and ports work is not very user friendly. However it's possible I don't understand it. Let me describe what I think is my understanding: - If I do a "pkg update" with the default configuration it will grab the "quarterly" package snapshot from a directory. E.g. if I run it on February 2023 it will go get 2023Q1 ports built stuff and if I run it again in April 2023 it will jump to 2023Q2 ports built stuff automatically. - It looks to me like this is done by building packages from the quarterly ports snapshot and then dumping them in /quarterly on the mirrors. Building from head appears to go into /latest, if I understand right. - I can find no way to make "pkg" tell me what quarterly snapshot was used to build the current packages on the mirror. - I can find no way to make "pkg" tell me what quarterly snapshot index is on my local disk. - I can find no way to make "pkg" tell me what quarterly snapshot an individual installed package came from. - If in February I also do a "git checkout -b 2023Q1 .../ports.git I will get the corresponding ports snapshot. But come April either 1) It says on the 2023Q1 branch because all I do is a git pull, or 2) I must manually do a git checkout -b 2023Q2. This causes me to make the following observations: - pkg has the magic keyword `quarterly` which always gets the current quarter. git has no similar keyword (branch, tag, other magic). - Checking if ports and packages are in sync is hard. - Updating ports is more manual than updating packages, I have to figure out which quarter when I update ports. I think the most lightweight fix is to add a command to pkg that would print out the quarter for the on-disk and/or remote copy in the same format as the git tags. Now it's easy programmatically to verify both are in sync, or to write a script that jumps git /usr/ports forward when pkg starts emitting a new value. A medium effort fix would be to add a tag to ports git called "quarterly" that moves forward every quarter. Now as a sysadmin I can just always bring my tree current with "quarterly". A high effort fix is as a sysadmin I don't want to manage any of this across a fleet of servers. I would like to set some variables in /etc/periodic.conf (or maybe /etc/rc.conf) that do this automatically: PKG_UPDATE_QUATERLY="YES" PORTS_UPDATE_QUATERLY="YES" Then some magic (I'm thinking maybe the weekly periodic script) would automatically suck down new pkg and/or git checkout new ports when we cross a quarterly boundary. I never have to think about updating either one, and the built in checks for out of date software always stay current.
(In reply to Leo Bicknell from comment #4) > … what quarterly snapshot … Maybe more relevant to focus on the version of FreeBSD. For example: % uname -KU 1400093 1400093 % pkg info nano | grep -A 4 Annotations Annotations : FreeBSD_version: 1400078 repo_type : binary repository : FreeBSD Flat size : 2.73MiB % pkg info virtualbox-ose | grep -A 5 Annotations Annotations : FreeBSD_version: 1400093 cpe : cpe:2.3:a:oracle:vm_virtualbox:6.1.46:::::freebsd14:x64 repo_type : binary repository : FreeBSD Flat size : 170MiB % – nano was built when the version (1400078) was inferior to the currently running kernel and user environment, but this is fine; the application runs.
> Maybe more relevant to focus on the version of FreeBSD. For example: I'm not sure that addresses my concern, but perhaps my concern isn't valid? The scenario I run into from time to time is: - Install everything I need from packages. - Discover 1 package was built with compile time flags different than I need. - Rebuild that singular package from ports with the changed options. What I am trying to do as a result is make sure the port I build is the "same" as the package one in terms of patches and the like. And, then when an upgrade cycle comes I generally upgrade the packages and then have to rebuild the one singular port. I feel like that might be a common scenario, but perhaps not. In any event I'm simply trying to make sure I'm all in sync, ideally programatically. In the "a sysadmin can dream" category, I would love a world where I could tell pkg "xyz from ports with options MAKEOPT=FOO" and then "pkg install" all the normal packages and have it build xyz from the ports when I tell it to install that package, and similarly do the same when I upgrade. Basically turn them into one seamless bucket of software with the ability to pick and choose in a config file which comes from where.
(In reply to Leo Bicknell from comment #6) Side note: if you wrap text manually for Bugzilla, please make your texts narrower. I have a user script that widens things, online, however most readers (and recipients of email) will find raggedness. Thanks