Please add better version management in the pkg install.

C

CielRuby

There has to be a minimal_tested_target_level or something to have sepperate versions of the package uploaded for different freebsd releases, keeping it compatible.

I prefer FreeBSD 11.4 over newer because of SCO unix SVR compatibility, but a lot of BSD packages, I can't install. This is a main reason for me to go to the more popular debian apt, or mac (together with Windows ofc) (I also look at Chrome OS, Opensolaris and Tizen).

I have doubts if this feedback makes a difference, so I'm also interested if there is a better package manager.

For now I'll try out Darwin or UbuntuBSD (which canonical should really maintain), and that's sad, because that's skipping out on all hard work for FreeBSD packages.

Maybe if I ever have the mental energy to pick up my programming life again, after failing my study at 18 due to corona, I will contribute something, but that's unlikely.

So thank you for reading.
 
Last edited:
Please note that this forum is more for users helping users. Bug reports or requests for enhancement should go to https://bugs.freebsd.org/bugzilla/, FreeBSD's bugzilla.

As someone who was hospitalized by Corona (all better now though), I sympathize with how it can sap your energy and wish you a speedy recovery. (I was an early adapter, catching it in April of 2020, when the CDC in the US was still recommending malaria medicine for what seems to have been political reasons).
 
OP: FYI - packages, and ports for that matter, have nothing to do with the FreeBSD base OS. All packages and ports are maintained by volunteers. Having said that, I am guessing there reason why ports and packages are for the current release is it would probably be a nightmare to maintain multiple versions because of dependencies. Just a guess on my part.

Hate to say it but software modernizes and moves on, good or bad.
 
CielRuby said:
There has to be a minimal_tested_release_level or something to have sepperate versions of the package uploaded for different freebsd releases, keeping it compatible.

I prefer FreeBSD 11.4 over newer because of SCO unix SVR compatibility, but a lot of BSD packages, I can't install.
Click to expand...

This is a considerable problem that I certainly can't see macOS or Darwin solving it. Windows does have very good backwards compatibility and for Debian, they do similar to FreeBSD.

So for FreeBSD what you likely want to do is set up a Jail containing an old release of FreeBSD. I.e so on my FreeBSD 13 amd machine, I run a jail containing a FreeBSD 9 i386 userland. If you need different architectures, you can use qemu-static but this is unlikely.

This old userland will provide the environment needed for your older software and yet runs in the very latest kernel (so you benefit from drivers etc). Graphics can be passed out seamlessly via the fantastic and unrivalled capabilities of X11 (something Apple software fails to support and Linux users are keen to break).

Alternatively you can also use a chroot like I would on Devuan.
 
CielRuby said:
I prefer FreeBSD 11.4 over newer because of SCO unix SVR compatibility, but a lot of BSD packages, I can't install.
Click to expand...
I'm wondering which packages you can't install? All versions of FreeBSD use the same ports tree and thus have the same packages available to them.

At the moment there is a problem with a bunch of KDE ports because of their dependency on OpenSSL 1.1.1. FreeBSD 11.4 only has OpenSSL 1.0.2 in the base. But if you build from ports you can set DEFAULT_VERSIONS+= ssl=openssl to use the port OpenSSL instead. Then those ports can be built on 11.4. The official packages however are always built using the default settings (for SSL that means using the base OpenSSL), which means these specific ports are going to fail to build (and thus no packages).

In any case, FreeBSD 11.4 (the entire 11 branch actually) will be EoL in a few months though.
 
Sorry to hear that you struggle as well, I wish you the best!
I didn't catch it though, I just failed because of homeschooling of too underdeveloped education and I'm receiving clinical treatment for depression (I think I have a youth-trauma), but I'm also shocked and worried about how the virus impacts each victim.
Damn China and the travelsystem (respect, just my opinion).

Thank you for the very useful link and the very fast response!
I love seeing a good community like this going forward.

Maintaining multiple versions is indeed horrible, but if every package has a minimal tested target level, then every package can be updated to support higher dependencies, or the inappropiate target level can change online, so the user gets prompted to downgrade, so the software requiring it works again, or just bundle it's own version of dependencies. The pkg install can also prompt to try to install a package history not having a lower or equal target level available if it's dependencies have.

So nice that the devs have a bugzilla!
 
Thank you for describing why FreeBSD is so awesome! Macos also used to have something like jail, the classic environment, so I'd be happy to use it some time, nice that it supports different archs, like Chrome os emulates arm.

My first x11 i used for freebsd was common desktop environment, I wanted something standard and Gnome 3 isn't in the 11.4 pkg command. Is that also because of SSL I heard gnome3 had systemd specific code, bad habits.

If they supporting 11.4, then I will make and support my own derriative lol.

Also, I believe being popular automatically makes packages better available, every os has it's advantages.
I like the freedom to support old operating systems for my software, something crazy like windows 98, that's good compatibility, but not a good OS like FreeBSD to develop on.
 
CielRuby said:
I wanted something standard and Gnome 3 isn't in the 11.4 pkg command.
Click to expand...
It should be there. But I see it was skipped on the latest builds due to issues with GTK4. Gnome3 "lite" also failed, because a dependency failed to build. These things can happen with any version. Will probably be fixed soon. Then the packages will be available again.

CielRuby said:
I heard gnome3 had systemd specific code, bad habits. Is that also because of ssl?
Click to expand...
A whole bunch of completely unrelated things.
 
Without reading every word of these walls of text: Is this maybe just because of the FreeBSD strategy to build package repositories? In case of build failures (for whatever reason), the affected package will be missing, cause that's the safer choice than keeping an older and maybe incompatible build. So, if you're using packages and one is missing, just try again a few days later…
 
CielRuby said:
package has a minimal tested target level
Click to expand...
FreeBSD has pre-compiled packages that are faster to install than compiling ports yourself. Those pre-compiled packages are probably what you're looking for - they're compiled with minimum needed flags enabled in the makefile. FreeBSD does that for several reasons - shorter compile time, less chances of dependency hell, easier to check that the package will actually run and not break anything else.

I personally prefer ports over pre-compiled packages, but they are more work.

As for maintaining multiple versions - that's what devel/git is for. FreeBSD does have a way to keep things organized.
I myself am still in the process of getting a handle on how it's working. At times, I had to adjust how I look at things just to make sense of what I'm looking at. For example, when figuring out how ZFS snapshotting works, just yesterday I realized that it's comparable to a telescoping fishing pole or a LIFO stack - last taken snapshot is the one to revert the system to. If you want to revert to something ealier, be prepared to let go of the more recent snapshot(s).
 
shkhln said:
Say what?
Click to expand...
Yeah, I know.
SirDice said:
bunch of completely unrelated things.
Click to expand...
I fixed the sentence order.
Nice to hear that the build will be fixed soon.
Zirias said:
In case of build failures (for whatever reason), the affected package will be missing, cause that's the safer choice than keeping an older and maybe incompatible build. So, if you're using packages and one is missing, just try again a few days later…
Click to expand...
I totally disagree because what if it worked yesterday and what if they are never gonna fix it on purpose or by accident. But that's not my choice and thank you for giving hope and patience.

I agree that the port system is a good alternative.

ZFS is a really interesting file system, I even use it in Ubuntu.
 
but when it's close to EOL, it will never get fixed, always leave with wreckless abandon.
It won't break if you don't update.
Otherwise new packages just need backwards compatibility for it's target lvl's old packages and only drop compatibiility migrating to the target level of the next BSD.
 
What the hell are you talking about? Nothing is ever abandoned, the ports tree is always built on all supported FreeBSD versions.

There's no "backwards compatibility to old packages" needed for that. There's only one ports tree, it's for all FreeBSD versions.
 
Also, keep in mind if you do use the ports.txz provided on the release .iso image, it is very possible to be able to keep using that and even merge the occasional "updated" port in from the very latest ports tree, particularly if it is a "leaf" port (nothing depends on it).

The way the ports (and compiling) works means that it will be compiled and linked against the versions you have installed (i.e the older ports collection). When it comes down to it, this really is the only viable solution available if you plan on maintaining a very old install.

That said, FreeBSD doesn't break that much, it is probably not necessary to worry so much about this. If a port does break, just grab a slightly older ports snapshot and merge that specific port in.
 
kpedersen said:
If a port does break, just grab a slightly older ports snapshot and merge that specific port in.
Click to expand...
Not the easiest thing to do... unless you're familiar enough with git to go back and forth like that. I only know that it's possible, but figuring out the exact commands - that's a rather tall order. I still haven't grasped the importance of git init, or a lot of other commands necessary to accomplish going back correctly. I spent a few hours trying to fish out the 40-character SHA1 hash code for a specific version of FreeBSD ports that I wanted to grab - from just a couple weeks ago. And why exactly? because those SHA1 hash codes are easier to use than stringing together a bunch of different commands to pull in a copy of the repo that is timestamped with the exact timestamp I need.
 
astyle said:
Not the easiest thing to do... unless you're familiar enough with git to go back and forth like that.
Click to expand...
True enough. However a very easy one to grab is the older one provided on the RELEASE iso / img media. For my personal uses, I rarely find myself having to hunt down a specific hash. I tend to go for quite large jumps.

For example, in any of these RELEASE folders here you will find a ports snapshot with varying age: https://download.freebsd.org/ftp/releases/amd64/amd64/
 
Stick with the RELEASE version of your choice and learn to compile ports.

UbubtuBSD

Somebody should wash their mouth out for naming it that.
No, their wetware needs dry cleaned for even thinking of that abomination.
 
astyle said:
FreeBSD has pre-compiled packages that are faster to install than compiling ports yourself. Those pre-compiled packages are probably what you're looking for - they're compiled with minimum needed flags enabled in the makefile. FreeBSD does that for several reasons - shorter compile time, less chances of dependency hell, easier to check that the package will actually run and not break anything else.
Click to expand...
By flags I assume you're referring to options and that's not true, the default options are a tradeoff between functionality, dependencies and potential conflicts. Think of it as "this should serve the vast majority of users fine".
 
Juggling the order a little …

CielRuby said:
… pick up my programming life … I prefer FreeBSD 11.4 over newer because …
Click to expand...

If you'll program, aim to get friendly with FreeBSD 14.0-CURRENT. It's bleeding edge, but I never felt bloodied.

Sevendogsbsd said:
… packages, and ports for that matter, have nothing to do with the FreeBSD base OS. …
Click to expand...

Not entirely true.

We have PkgBase, which can be used to install, update and upgrade the base operating system, although PkgBase itself is not release quality. Discussion:
CielRuby if you'll work with 14.0-CURRENT: assuming AMD64, aim for <https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/14.0/> (not <https://download.freebsd.org/ftp/snapshots/VM-IMAGES/14.0-CURRENT/amd64/Latest/>) and when installing:
  1. choose ZFS, not UFS
  2. give plenty of the disk to the partition for swap – I typically choose 16 G or greater.
(Those two points can equally apply to 13.0-RELEASE …)

CielRuby said:
sepperate versions of the package uploaded for different freebsd releases
Click to expand...

FreshPorts can be ideal for gaining overviews. Three examples below.

Surf is unusual in that <https://www.freshports.org/www/surf/#add> the name of the package differs from the name of the port. There is no flavour information for this port.

Falkon is an example of a port for which there are multiple flavours. <https://www.freshports.org/www/falkon/#flavors> shows the two. Down a little, <https://www.freshports.org/www/falkon/#packages> two tables of packages.

Pycairo is presented has having just one flavour <https://www.freshports.org/graphics/py-cairo/#flavors> and there are four tables of packages <https://www.freshports.org/graphics/py-cairo/#packages> – one for each version of Python.

FreshPorts also displays dependencies.


<https://cgit.freebsd.org/ports/tree/UPDATING> is effectively your README.txt for ports, excluding PkgBase.

<https://cgit.freebsd.org/ports/tree/UPDATING?id=210ee04dd3c3f2e82cd3130e412866a182066859#n8> the point in time when the default version of python3 and python was switched to 3.8.

Here in FreeBSD Forums it's customary to express the origin, and use the available markup, so [PORT]www/surf[/PORT] appears as www/surf.

To know the origin for a package, you can use pkg-rquery(8), for example:

Code: 
% pkg rquery -r FreeBSD '%o %v %R' surf-browser
www/surf 2.1 FreeBSD
%

CielRuby said:
Macos also used to have something like jail, the classic environment,
Click to expand...

Very loosely speaking (I'm not a programmer): if you liked Apple's Classic, you'll like FreeBSD's Linuxulator.

Update on FreeBSD Foundation Investment in Linuxulator | FreeBSD Foundation (not visibly dated, 2021-04-09)


Last but not least: GhostBSD, which is based on FreeBSD stable/13, uses a single repository of packages to upgrade and update:
  • the base operating system
  • extras (like, what's in FreshPorts for FreeBSD).
GhostBSD OS packages are built from ports (not from ghostbsd-src): <https://github.com/ghostbsd/ghostbsd-ports/tree/master/os>


Whilst the GhostBSD approach to packaging the base operating system is comparable to PkgBase for FreeBSD, I expect FreeBSD to always keep OS packages in separate repositories.
 
Thank you for all your replies, I love experimenting with all of it, including the linuxulator!
I only used 11.4, because I had the wild idea of programming a Pe Windows emulator on top of the coff compatibility.
But, while playing with it I got a little concerned about package system. Thank you for giving me the bigger picture!
Edit: What is an Ububtu XD!
 
grahamperrin said:
Please, how do you see? Do you have access to ampere* and beefy* hosts?

https://pkg-status.freebsd.org/builds?type=package&jailname=114amd64
Click to expand...
Click on the tiny poudriere icon (looks like a bomb with a face). Or use the filter icon (looks like a funnel) to filter on specific build servers, repositories or jails.

You get to see this for example: http://beefy3.nyi.freebsd.org/build.html?mastername=114amd64-quarterly&build=039c0c283e0f
Then look at the failed, skipped or ignored ports. Use the search to find a specific port. The reason why it failed, skipped or ignored is mentioned. Then you could look at the build logs for that specific port or dig further if it's skipped or it failed due to a dependency. It often takes a little digging to find the exact reasons why something failed.
 
You must log in or register to reply here.
Back
Top