# Please add better version management in the pkg install.



## CielRuby (Jun 1, 2021)

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.


----------



## scottro (Jun 1, 2021)

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).


----------



## Sevendogsbsd (Jun 1, 2021)

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.


----------



## kpedersen (Jun 1, 2021)

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.



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.


----------



## SirDice (Jun 1, 2021)

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.


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.


----------



## CielRuby (Jun 1, 2021)

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!


----------



## CielRuby (Jun 1, 2021)

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.


----------



## shkhln (Jun 1, 2021)

CielRuby said:


> because of SCO unix SVR compatibility


Say what?


----------



## SirDice (Jun 1, 2021)

CielRuby said:


> I wanted something standard and Gnome 3 isn't in the 11.4 pkg command.


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.


			https://pkg-status.freebsd.org/builds?jailname=114amd64
		




CielRuby said:


> I heard gnome3 had systemd specific code, bad habits. Is that also because of ssl?


A whole bunch of completely unrelated things.


----------



## zirias@ (Jun 1, 2021)

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…


----------



## astyle (Jun 1, 2021)

CielRuby said:


> package has a minimal tested target level


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).


----------



## CielRuby (Jun 1, 2021)

shkhln said:


> Say what?


Yeah, I know.


SirDice said:


> bunch of completely unrelated things.


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…


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.


----------



## CielRuby (Jun 1, 2021)

Also thank you all for giving me insight about how it works. That's handy for the bug report.


----------



## zirias@ (Jun 1, 2021)

CielRuby said:


> I totally disagree because what if it worked yesterday


It will break eventually and unpredictably.


CielRuby said:


> and what if they are never gonna fix it on purpose or by accident


Will never happen. To begin with, there's a pkg-fallout mail to the maintainer of the port affected. Of course, there would be problem reports pretty soon as well.


----------



## CielRuby (Jun 2, 2021)

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.


----------



## zirias@ (Jun 2, 2021)

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.


----------



## kpedersen (Jun 2, 2021)

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.


----------



## astyle (Jun 3, 2021)

kpedersen said:


> If a port does break, just grab a slightly older ports snapshot and merge that specific port in.


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.


----------



## kpedersen (Jun 3, 2021)

astyle said:


> Not the easiest thing to do... unless you're familiar enough with git to go back and forth like that.


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/


----------



## Deleted member 30996 (Jun 3, 2021)

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.


----------



## grahamperrin@ (Jun 13, 2021)

SirDice said:


> … I see it was skipped on the latest builds due to issues with GTK4. …



Please, _how_ do you see? Do you have access to ampere* and beefy* hosts?



			https://pkg-status.freebsd.org/builds?type=package&jailname=114amd64


----------



## diizzy (Jun 13, 2021)

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.


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".


----------



## grahamperrin@ (Jun 13, 2021)

Juggling the order a little …



CielRuby said:


> … pick up my programming life … I prefer FreeBSD 11.4 over newer because …



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. …



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:

<https://forums.freebsd.org/threads/79917/>
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:

choose ZFS, not UFS
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



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:


```
% 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,



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.


----------



## CielRuby (Jun 13, 2021)

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!


----------



## SirDice (Jun 13, 2021)

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 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.


----------



## grahamperrin@ (Jun 13, 2021)

Thanks, this effectively answers my question about your access to ampere* and beefy* hosts.



SirDice said:


> … You get to see this for example: http://beefy3.nyi.freebsd.org/build.html?mastername=114amd64-quarterly&build=039c0c283e0f …



– not me.

We plebs get to see this, for example:




<https://old.reddit.com/r/freebsd/comments/nujgxe/-/h1gv3ra/?context=2 >

I can find my way around poudriere build logs on my own computer and elsewhere. 

There must be good reasons for no public access to ampere* and beefy* hosts. I have no argument, but it leaves us somewhat in the dark.


----------



## SirDice (Jun 13, 2021)

grahamperrin said:


> There must be good reasons for no public access to ampere* and beefy* hosts. I have no argument, but it leaves us somewhat in the dark.


I don't have any "special" access as far as I know. If I do then nobody told me.


----------



## astyle (Jun 13, 2021)

grahamperrin said:


> Thanks, this effectively answers my question about your access to ampere* and beefy* hosts.
> 
> 
> 
> ...


Funny... I clicked the URL provided by SirDice , and got to beefy3 just fine, no special config needed. This suggests a network hiccup somewhere along the way. Just hit f5.


----------



## astyle (Jun 13, 2021)

diizzy said:


> 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".


Yeah, until you try multimedia/vlc. The pre-compiled package has so few options enabled, subtitles didn't work at all, and there was no x264/x265... I don't think that would exactly "serve vast majority of users just fine". That was the minimum needed to even run VLC without conflicting with other ports. But compiling VLC with all the Makefile flags / options turned on - that created an install that had everything VLC is famous for.

Oh, and BTW - 'Conflicts' within a given ports tree usually happen when 2  or more different ports try to install different versions of the same lib to the same place - e.g., libglut.so from graphics/freeglut v.3.0 or libglut.so from graphics/freeglut v.2.4... but that is usually taken care of BEFORE the ports even make it into the ports tree that public can download.


----------



## diizzy (Jun 13, 2021)

astyle said:


> Yeah, until you try multimedia/vlc. The pre-compiled package has so few options enabled, subtitles didn't work at all, and there was no x264/x265... I don't think that would exactly "serve vast majority of users just fine". That was the minimum needed to even run VLC without conflicting with other ports. But compiling VLC with all the Makefile flags / options turned on - that created an install that had everything VLC is famous for.
> 
> Oh, and BTW - 'Conflicts' within a given ports tree usually happen when 2  or more different ports try to install different versions of the same lib to the same place - e.g., libglut.so from graphics/freeglut v.3.0 or libglut.so from graphics/freeglut v.2.4... but that is usually taken care of BEFORE the ports even make it into the ports tree that public can download.


That's one port and I honestly think it's an oversight, submit a PR that enableds libass and you should be fine. I don't see why you'd need x264 and x265 as they're provided by ffmpeg.
As a sidenote, mpv has support out of the box from what I can tell.


----------



## rigoletto@ (Jun 13, 2021)

grahamperrin said:


> Thanks, this effectively answers my question about your access to ampere* and beefy* hosts.
> 
> 
> 
> ...



I think this is IPv6 only.


----------



## astyle (Jun 13, 2021)

diizzy said:


> That's one port and I honestly think it's an oversight, submit a PR that enableds libass and you should be fine. I don't see why you'd need x264 and x265 as they're provided by ffmpeg.
> As a sidenote, mpv has support out of the box from what I can tell.


I want to watch my animes tonight, and not have to hunt for the links to do all that, and then wait for the devs to finally pay attention to my PR and make it available. I'd do that kind of thing (submit a PR) with KDE and Wayland, then I can just sit back and wait. Besides, you can compile ffmpeg without x264/265. Separate ports. FWIW, ffmpeg comes without those 2 enabled in the default config.

Besides, who'd want to spend time fine-tuning every single one of those 40K+ ports? the devs just do the minimum to get clang to shut up and build, and to be able to power through the entire collection without stopping.


----------



## diizzy (Jun 14, 2021)

astyle 




__





						256593 – multimedia/vlc: Enable support for subtitles by default and add missing deps
					






					bugs.freebsd.org
				




Out of curiosity, why do you need encoding support in vlc (decoding is already handled by ffmpeg) for your anime?
I would personally however recommend mpv over VLC for playing video though. =)


----------



## astyle (Jun 14, 2021)

diizzy said:


> astyle
> 
> 
> 
> ...


To reply to that, you'd need to know how the software is structured. 

FFmpeg uses truckloads of different libs to handle encoding and decoding. Most of those libs are actually separate ports in FreeBSD. You can compile FFmpeg without those libs, but then it won't be quite as capable.
x264, x265, and libASS (ASS stands for Advanced Sub Station alpha, BTW) are actually separate sub-projects from the VLC project (don't believe me, go to videolan.org to check that out). They are separate ports. And yes, that's what VLC uses for decoding - not ffmpeg proper.
FFmpeg can be compiled against the exact same version of the libs I mentioned in item 2, but ffmpeg proper is not a backend to VLC.
FWIW, mpv is compiled using exact same libs as VLC and FFmpeg. I prefer VLC because it has a richer UI, which offers me options and fine-grained control. If you compile VLC with all the possible options enabled, it's quite functional.


----------



## diizzy (Jun 14, 2021)

It's getting off topic but this is the last time I'll answer this... ;-)

1. Yes? FFmpeg can make use of different external libraries however most are actually not for decoding video itself instead encoding, handing other types of data (subtitles etc), APIs,  and so on which wouldn't affect your
2.  The VideoLAN organisation were indeed involved in developing (lib)x264 which is an encoder .
Reference: https://code.videolan.org/videolan/x264/ "x264, the best and fastest H.264 encoder"
(lib)x265 which is based off (lib)x264 were however developed by MultiCoreWave and not VideoLAN organisation
Reference: https://en.wikipedia.org/wiki/X265
libass were initally developed by Evgeniy Stepanov (not a VideoLAN organisation member of affiliate as far as I can tell) and several years later Grigori Goronzy continued who is listed as a member however it's no clear from a quick view if work was done affiliated with VideoLAN or not. Not that this really matters except for libass which handles a few subtitle formats that VLC supports (not all though).
I also think you've misunderstood a bit what each library does, (lib)x264 and (lib)x265 are only used for encoding as that's what they're designed to do.








						configure.ac · 3.0.15 · VideoLAN / VLC · GitLab
					

VLC: the ultimate media player




					code.videolan.org
				











						modules/codec/x265.c · 3.0.15 · VideoLAN / VLC · GitLab
					

VLC: the ultimate media player




					code.videolan.org
				











						configure.ac · 3.0.15 · VideoLAN / VLC · GitLab
					

VLC: the ultimate media player




					code.videolan.org
				











						modules/codec/x264.c · 3.0.15 · VideoLAN / VLC · GitLab
					

VLC: the ultimate media player




					code.videolan.org
				



3. FFmpeg does however handle the bulk of all formats that VLC supports
https://code.videolan.org/videolan/vlc/-/blob/3.0.15/modules/codec/avcodec/avcodec.c#L71 (feel free to dig around more in the source code if you want)
4. That's fine however the render in mpv and mkv support were (at least a few years back) considered better compared VLC but both will do fine for most work and there might be as big of a performance gap these days.


----------



## scottro (Jun 14, 2021)

A few things, though I guess it's gotten off-topic.  I believe the ffmpeg default package handles x264 and x265--I submitted a PR for that years ago and they did it in two days or so.

I install it from pkg. Just doublechecked it definitely enables x264 and 265. (And ass, but not sure if that was under discussion).


----------



## astyle (Jun 14, 2021)

scottro said:


> A few things, though I guess it's gotten off-topic.  I believe the ffmpeg default package handles x264 and x265--I submitted a PR for that years ago and they did it in two days or so.
> 
> I install it from pkg. Just doublechecked it definitely enables x264 and 265. (And ass, but not sure if that was under discussion).


Can't exactly count on being that lucky with packages after submitting a PR... For example, audio/lash has no maintainer, is marked as 'broken', v. 0.5.14 is the one in ports, nobody bothered to prune it because it's an optional dependency for audio/ardour6 (you'll see that only with a `# make config` in /usr/ports/audio/ardour6). The most recent version of LASH is 0.6.0 (per GNU's git repo), but even that is circa 2008... My point is, it would be pointless to submit a PR for an abandoned port that  was never properly pruned out of the ports tree.

Having studied a bit on the process for making a change to the FreeBSD's pre-compiled packages - I can say that there's not that many devs/projects who'd have a good enough handle on the process to do it as fast as was the case for you...


----------



## scottro (Jun 14, 2021)

I didn't mean to imply that it always gets done that fast. I've been lucky.


----------

