Downloading Package Binaries

T

Tridac

Still running 14.2 on one machine, and next major upgrade won't be until next spring. Seemed like a good idea to have a local copy of all port binaries, so using pkg fetch, as follows:

pkg fetch -a -s -o /export/nfs/sas4x3840/freebsd-ports/14

Still downloading, but question is, will that port collection be for 14, or something else ?.

Did try to find other repositories, which are there, but all seem to be virtual addresses, url not recognised, so unable to specify the download directory.

Thanks, Chris
 
Tridac said:
Still downloading, but question is, will that port collection be for 14, or something else ?.
Click to expand...
It's a package collection, not a port collection. And they'll be for 14.4 at this time. They're not going to work on 14.2.
 
Thanks, that was what was wanted, but have installed a few packages recently, and they do work, though do get a warning about possible incompatabilites. It's on my head alone, a compromise, until the next major upgrade next year. So, assume whatever uname is running, pkg fetch will download the correct packages.

Perfection and doing it right are always the ideal, but the real world of engineering is often a compromise:-).
 
Tridac said:
Thanks, that was what was wanted, but have installed a few packages recently, and they do work, though do get a warning about possible incompatabilites. It's on my head alone, a compromise, until the next major upgrade next year. So, assume whatever uname is running, pkg fetch will download the correct packages.

Perfection and doing it right are always the ideal, but the real world of engineering is often a compromise:-).
Click to expand...
When you do a normal upgrade, or install packages from a pkg repository that have a newer userland, you do get a warning about it (here is an example for 15.1 ):

Newer FreeBSD version for package zxfer:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1501000
- running userland: 1500068
Ignore the mismatch and continue? [y/N]:
Click to expand...
 
Correct, but at least there is the choice to take the risk. This just exposes the differences between os developers and end users. Modern os systems are so complex, and things move so fast, that a rigid discipline must maintained to avoid chaos. End user developers. on the other hand, just want to use the os to get real work done, with all the compromises and work arounds that that can entail. That is, gettng the job done, whatever that takes.

I'm just grateful that we have a first class os like FreeBSD for anyone to use. With features like ZFS, jails, and straightforward configuration, the closest I have ever seen to the boring, but very effective Solaris 10. No other open sourse os gets close, and I do try to test several new releases of many distros every year.
 
Usually, pkgs of non-kmod ports built against newer minor versions may work.
If you're lucky enough (not recommended, though), you can run non-kmod "binaries" built for FreeBSD 4.x on 16-CURRENT with GENERIC kernel by installing below.
  1. misc/compat4x
  2. misc/compat5x
  3. misc/compat6x
  4. misc/compat7x
  5. misc/compat8x
  6. misc/compat9x
  7. misc/compat10x
  8. misc/compat11x
  9. misc/compat12x
  10. misc/compat13x
  11. misc/compat14x
  12. misc/compat15x
Scripts for languages in ports/pkgs would be the different story as of the lack of backward compatibilities per specific language.
 
Don't remember ever using the compat libraries, but may have been included, perhaps in buiding an older port, with no current maintainer.

Had a progect some years ago (2016 ?), when I was still in Sun fanboy mode, where i wanted to get some frame buffer support for Ultra Sparc, for which FreeBSD (all os's ?) frame buffer support was bit sparse. Thinking, why not run it headless, with vnc across the network ?. Iirc, the FreeBSD version was 11.1, or close. Anyway, ended up building probably hundreds of ports, starting with xvnc, then the simplest frame buffer drivers, and ending with xvnc. All built with barely a warning, from memory, and still have that installed on a Sun V215. A vnc client does work, a bit glacial at load, but once a shell ot two are open, prerfectly usable. More proof of concept, rather than anything else, but was quite amazed as to how easily, all the ports built. That shows robustness. Don't know if anyone else would be interested in that, but have system dmp files, which should load straight back onto another machine. May have to adjust the network device id's, but a generic kernel, so should work on a variety of Sun machines..
 
Within minor versions like 14.2-14.4 older stuff is required to work on newer but newer is not required to run on older.

With that said, sometimes it works anyway like the php patches that were hullabalooed yesterday.

/grandpa
 
I've found it pretty flexible, and one can make tradeoffs as to the risk. The main gotcha being the inability to build older packages from source, as there ar no binaries. The answer here has been to install the older version os, then build from ports. Always install jails as thick jails as well, which provides isolation from the main os of any version, and allows exclusive ownership of a network interface, which can be on a different subnet, another essential aid to security. It's about ways to develop best practices for the sort of work being done.
 
Tridac said:
Always install jails as thick jails as well, which provides isolation from the main os of any version
Click to expand...
Thin jails do to. This isolation from the host OS is the whole point of a jail(8), regardless if it's a 'thick' or 'thin' jail. But the jail can never be newer than the host (14.4 jail on 14.2 host for example), the other way around is not a problem (14.2 jail on a 14.4 host). This is because a jail runs on the host's kernel, it does not have a kernel itself. The kernel is always backwards compatible, not forward.

Packages built for 14.4 may or may not run without problems on a 14.2 system, it's not guaranteed and definitely not a supported set up.

Anyway, I would upgrade the system to 14.5 (14.4 will be EoL soon) now, it's fine if you want to postpone the major version upgrade, the latest minor version of the 'legacy' 14 branch is still supported for a while (14.6 is tentatively scheduled for March 2027).
 
To clarify, i'm aware that a thin jail shares the main os kernal, but understood that a thick jail runs from its own kernel ?. Otherwise, what is the point of a thick jail ?. Afaics, for best security, it should extend right down to hardware level, as you have to assume that security measure in software alone, could be hijacked, given unlimited / determined resources. Would never even consider sharing a single network interface device across different subnets. Hardware is cheap enough to avoid that.
 
Tridac said:
but understood that a thick jail runs from its own kernel
Click to expand...
Nope. A jail(8) runs in a separate namespace on the host's kernel. This separated namespace is what provides the isolation. A virtual machine (bhyve(8) for example) would have more (hardware-level) isolation, but even that could be broken out of due to bugs or other issues.
 
You must log in or register to reply here.
Back
Top