Preferred method of updating /usr/ports/UPDATING file for use with pkg updating

O

ondra_knezour

Probably most users nowadays use packages and don't update their /usr/ports anymore. What is preferred method to update /usr/ports/UPDATING for use with the pkg updating command?

I did not find any in manual pages and searching for "freebsd ports updating pkg updating" is quite useless :)
 
Hm, not sure whether there's some dedicated mechanism for that, but you can just fetch one directly from cgit for example:

fetch https://cgit.freebsd.org/ports/plain/UPDATING

Or, for the current quarterly:

fetch -oUPDATING "https://cgit.freebsd.org/ports/plain/UPDATING?h=2023Q2"
 
BTW, this can be combined to a pipe for something like an "online query" ? E.g. for quarterly:

fetch -qo- "https://cgit.freebsd.org/ports/plain/UPDATING?h=2023Q2" | pkg updating -f/dev/stdin | less
 
I know I can get single file from ports repository, but I am not so sure how to automagically get the one which describes notes for set of packages currently residing in latest quarterly repository. Should we try to persuade someone that matching UPDATING file have to be part of each package repository?
 
ondra_knezour said:
I know I can get single file from ports repository, but I am not so sure how to automagically get the one which describes notes for set of packages currently residing in latest quarterly repository.
Click to expand...
There's only one UPDATING file. It's not split up, it's just one file that has multiple entries. The commands zirias@ showed fetches the latest copy of it and pipes it through pkg-updating(8).
 
It is only one file, but it has history. And fetching latest version may not be exactly relevant to packages in latest quarterly built let say two month ago.

Imagine new quarterly build on January 1st. Few days later you decide to install something, including ThePackage v1.2. Then on April 1st new quarterly set is build, including new version of ThePackage, v1.3. Later in May, ThePackage v2.0 hits the ports with UPDATING entry about switching from MySQL to PostgreSQL. When you decide to update in June to v1.3 in Q2 quarterly, you don't want (yet) not relevant noise about MySQL dropped.
 
You got me, almost :) I did, couple of times in last twenty something years, last time about 11:25 today.

I don't know, how I can better explain myself.

Entry from UPDATING
Code: 
20181014:
  AFFECTS: users of sysutils/ansible
  Ansible has been updated to 2.7.0. Please follow the porting guide
  to update the rulesets...

Let say that on October 1st 2018 quarterly have been built including Ansible 2.6.7. Above entry did not exists at that time and so it should not be present to curious user who want check pkg updating at October 30th before upgrade, because it is not relevant for his 2.6.x -> 2.6.7 upgrade path.

My reasoning goes further, pkg updating may gain option to show only entries relevant to installed packages newer than currently installed packages (something like for PACKAGE in pkg info do pkg updating -d date_of_installation $PACKAGE), but we are not there yet.
 
ondra_knezour said:
Let say that on October 1st 2018 quarterly have been built including Ansible 2.6.7. Above entry did not exists at that time and so it should not be present to curious user who want check pkg updating at October 30th before upgrade, because it is not relevant for his 2.6.x -> 2.6.7 upgrade path.
Click to expand...
:-/ ❓

ondra_knezour said:
My reasoning goes further, pkg updating may gain option to show only entries relevant to installed packages newer than currently installed packages (something like for PACKAGE in pkg info do pkg updating -d date_of_installation $PACKAGE), but we are not there yet.
Click to expand...
You're overcomplicating things. It's a file, with entries in reverse chronological order. Just read it back to when you last upgraded packages.
 
I don't think that "show me only notes relevant for available upgrades" is too demanding or overcomplicated, but I utterly respect anyone's need to do it manually :)
 
To put it into perspective, I wouldn't even trust the filtering pkg updating is doing. It applies pattern matching to the "AFFECTS" field of these entries. There are a lot of ways thinkable how that could accidentally skip a relevant entry.

It's not like there are a huge number of entries in UPDATING. Quite the opposite, needing to document something there is pretty rare. IMHO, the safe choice is to just read the whole file (ofc only down to the date relevant for you).
 
Alain De Vos said:
Or grep the relevant lines fields, your interest.
Click to expand...
I would assume pkg updating doing the job at least as well as manual "grepping". But the issue is, correlating entries in UPDATING to ports/packages is only possible by pattern matching, so although this probably works very reliably, there's no way to guarantee it would never miss an entry that could be relevant to you.

Given the small number of entries (e.g. I currently count 21 for the whole first quarter of 2023), I opt to better scan them all.
 
Sure, automatic filtering is now very approximate at the best, given we have entries like db/program_name[10-12], but it is another can of worm for which infrastructure is not there (yet). What I am looking for is already available, we know when was package installed, from what repository, what is missing is link to the UPDATING file in corresponding branch/tag/commit, fetching it, get upgradable packages and relevant UPDATING entries newer than last installation datetime for given package. This can be even run from periodic for avid readers :D
 
You must log in or register to reply here.
Back
Top