pkg upgrade

It downloads current version numbers from remote repository and compares it to the version details that are stored on your machine. pkg basically uses a sqlite database at /var/db/pkg/local.sqlite for that purpose.
If you let us know what parts in particular you're interested in, I might be able to point out further details (i.e. version comparison, package meta data etc.).
 
I'm basically interested in manually putting together my own local pkg repo, but am unclear as to whether pkgs with different ABI's need their own repositories. I guess some pkgs will work with different releases of FreeBSD and some won't. Sorry if this sounds hazy but I'm only just beginning to marvel at the depths of the pkg management system of FreeBSD and how everything works together.

Can you tell me what info packagesite.yaml provides?
 
I'm basically interested in manually putting together my own local pkg repo, but am unclear as to whether pkgs with different ABI's need their own repositories. I guess some pkgs will work with different releases of FreeBSD and some won't.
They may/can be used on different systems if the Makefile f.e. makes use of "NO_BUILD" or "NO_ARCH", but: The dependencies of ports can change on newer versions (or maintainers temper), so they will differ over the time; Expect problems if you're putting together old packages and newer build packages (even if the portversion doesn't differ) - you may ran into false dependencies, even if pkg says everything's fine. It's no good idea to carry old packages from outdated FreeBSD versions to newer installations. It may work, but mustn't, so: Use packages built for FreeBSD 12 for FreeBSD 12, and packages built for FreeBSD 13 for FreeBSD 13. But do not mix them. There's nothing in the package repositories which can evaluate this.
And: There's a reason why your pkg command complained your package repository. https://forums.freebsd.org/threads/pkg-repo.80322/#post-512594
Can you tell me what info packagesite.yaml provides?
That file can be read. You're using Midnight Commander, so just enter your repositories packagesite.txz file, move to the (only) included file packagesite.yaml, and press [F3].
 
That file can be read. You're using Midnight Commander, so just enter your repositories packagesite.txz file, move to the (only) included file packagesite.yaml, and press [F3].

Thanks, I can view the file I just wondered where I could find a record layout for the lines.
 
Thanks, I can view the file I just wondered where I could find a record layout for the lines.
YAML:
{"keyword1":"value","keyword2":"value", …}
{"keyword1":"value","keyword2":"value", …}
…

So your YAML file contains just a list with a simple associative array: Every node ("package") is in braces, and for every node there's a list of keywords (like "name", "version" etc.) and its value (like "firefox", "89.0_1,2", etc.). Which keywords it uses you can read; Note that a value can contain another, new array with other key/values (so in this case f.e. "deps" - the dependencies). So its nested (a "multidimensional, associative array").

It's no fun to build the package meta file by yourself; While it looks quite simple I'm sure you will have to invest some days to program your alternative "pkg repo" command - even if your already firm in handling multidimensional, associative arrays, writing export files (escapes / special chars), handling data structures etc. Anyway, (nearly) all you need to write that file you'll get by just using pkg info in (afair three) different ways (once for all packages, twice for every package).
 
Those yaml files aren't actually yaml but JSON files. See also this thread for reference:

The content structure should be relatively self-explanatory if you use a parser for JSON, just like jmos pointed out. Some additional details may also be gleaned from pkg-repo():
packagesite.txz similarly contains at least one file packagesite.yaml,
which is a YAML document listing selected metadata for each of the pack-
ages in the repository. This is the key file containing the working data
used by pkg(8) and includes the run-time dependencies for each package,
plus shared library dependencies and similar data that are used by pkg(8)
to solve package dependency problems.
 
Those yaml files aren't actually yaml but JSON files.

I don't actually know what JSON files are although I hear the term all the time...

I think I have an aversion to the name because it reminds me of someone called JASON who diddled me out of a lot of money once.... but hey-ho...
 
Json looks like this,
Code:
[
   {
      "Naam":"JSON",
      "Type":"Gegevensuitwisselingsformaat",
      "isProgrammeertaal":false,
      "Zie ook":[
         "XML",
         "ASN.1"
      ]
   },
   {
      "Naam":"JavaScript",
      "Type":"Programmeertaal",
      "isProgrammeertaal":true,
      "Jaar":1995
   }
]
 
Back
Top