PKG is a total disaster

trev said:
I have some sympathy for Barney and experienced similar issues (with a non-EOL release) before reverting to compiling my own ports again with customized settings. I had been willing to forego some of the customisation for the supposed ease of updating, only to find the system was frequently uninstalling dozens of apparently unrelated packages just to update one, every time. (Yes, I had removed all my compiled ports before using the package system.)

I still have a use for the package system - it is quite trivial to create your own package (in this case SeaMonkey) for installation on other systems. That is now my only use of the package system.
Click to expand...
That's a good use case for rolling your own PKG repo with ports-mgmt/poudriere. I used to have the same problem, and ever since I migrated to using my own repo, package upgrades have been a lot less painful. You can build the entire ports tree or only the ones you need.
 
tuaris said:
shift towards non-shared library versions of ports
Click to expand...
Are you meaning like Flatpaks and similar?

So if I have 20 applications needing libxml2 then I potentially have 20 versions of libxml2 on a machine, one per application?

Not saying that's good or bad, trying to understand if that is the sort of thing you mean.
 
richardtoohey2 said:
Are you meaning like Flatpaks and similar?

So if I have 20 applications needing libxml2 then I potentially have 20 versions of libxml2 on a machine, one per application?

Not saying that's good or bad, trying to understand if that is the sort of thing you mean.
Click to expand...
Yes that's exactly what I mean. There is nothing wrong with having a copy of (for example) libxml2 for each application that needs it, even different versions (which I see as positive side effect). When it comes time to remove or update, the package management system keeps track of it.

And yeah, stuff like Flatpak, AppImage, Docker, containers, (and even jails) are sort of the same concept in a way.
 
I can see the attraction of something like Flatpaks but it just feels wrong and wasteful. If there's an issue in libxml2.10 (or whatever) - if I patch the one copy I have of it, and that fixes 10 or 20 applications, that seems more efficient, and I've fixed 10 or 20 applications just by doing one thing. In real life it means re-building or re-installing those applications, so that can be a pain. In the Flatpak scenerio all the authors/providers of the applications would re-build their Flatpaks and I'd re-install them.

Dunno. No silver bullets that's for sure!
 
richardtoohey2 said:
If there's an issue in libxml2.10 (or whatever) - if I patch the one copy I have of it, and that fixes 10 or 20 applications,
Click to expand...
Indeed as mentioned, that was part of the reasoning in favor of shared libraries.
Most of us are just mere mortals, and are not manually patching libraries ;)

richardtoohey2 said:
that seems more efficient, and I've fixed 10 or 20 applications just by doing one thing.
Click to expand...
With a command like pkg upgrade, it's the same thing. It might take a little longer, but still gets the job done.

richardtoohey2 said:
In real life it means re-building or re-installing those applications, so that can be a pain. In the Flatpak scenerio all the authors/providers of the applications would re-build their Flatpaks and I'd re-install them.
Click to expand...
Since you are using binary packages the OS vendor (ie. the FreeBSD pkg repos) would have already done that part for you. You are reinstalling those applications anyway when the library changes (which is the complaint of the OP).

Maybe there is a way to have both approaches and let people choose the one that works best for them, who knows. Just throwing ideas (good or bad) out there.
 
Caution please. The applications of my desktop env. all talk to each other. I dunno what happens when they're using different library versions regarding the protocols & conventions in use for that chatter.
 
Minbari said:
Actually SunOS is both. Until version 3 is BSD, after that had support for SysV too, but was still BSD based (4.1.4). Starting with 5.0 had only support for SRV4 and was rebranded as Solaris.
Click to expand...
Yeah, it was a weird time. I still don't quite get the versioning but I think for a while "Sun UNIX" mirrored the BSD version numbers but added "Release 2.0" for its specific version of SunOS.

So here we can see that SunOS 2 is based on BSD 4.2. At least I think that is how it went.

SUN2-emulator-booting-SunOS-2-1024x936.png
 
tuaris said:
non-shared library versions of ports? (for non-embedded)
Click to expand...
This seems similar to the sandboxing stuff that canonical is doing with snap, A traditional method is best, though storage is cheaper nowadays, it is extremely easy to bloat up systems with redundant libraries and packages.
 
tuaris said:
Maybe this is a good time to bring up the idea of a paradigm shift towards non-shared library versions of ports? (for non-embedded)
A few things have changed in the last 40 years that makes this a sensible thought:
Click to expand...

I agree whole heartedly. We a on a treadmill of interlocking revisions based on historical practice and not on current need. What is more expensive to an enterprise: a Terabyte of disk or days of a SysOps time? Consider OSX apps. These are self-contained applications that do not require one to pull down a slew of related apps to install.
Click to expand...
 
Meh, It'd be easy for me to run about and call the work of others a giant crump, then go off and live my life of ease, while implying others work without pay and improve it.

If that's the trend of FreeBSD I'd probably leave.

New developments happen because someone has a solution and the will to implement it.

Free software is supposed to be a fun and innovative way to share improvements with the world, it isn't a platform where people sign their lives over to perpetual bondage.

[Remember PBI files from TrueOS? That was one solution someone came up with several years ago. They look alot like these snap files from Linux. I think I remember installing the PBI system in GhostBSD, it seemed to have worked the same as with TrueOS/PCBSD.

I don't know if I am remembering correctly, but the largest problem was that the pbi files were very large. They had shared libraries, to reduce bloat within the system, they would version the libraries, but the actual files themselve were large because they included all necessary libraries regardless of whether they were already on the system.]
 
BostonBSD said:
[Remember PBI files from TrueOS? That was one solution someone came up with several years ago. They look alot like these snap files from Linux. I think I remember installing the PBI system in GhostBSD, it seemed to have worked the same as with TrueOS/PCBSD.

I don't know if I am remembering correctly, but the largest problem was that the pbi files were very large. They had shared libraries, to reduce bloat within the system, they would version the libraries, but the actual files themselve were large because they included all necessary libraries regardless of whether they were already on the system.]
Click to expand...
Those .pbi where indeed something really interesting for that time and the only good thing that came out from that project. The only flaw was that they where to big in size and the user had the same librery in many packages insted of a symlink or a sanbox for pbi libreries. Also instead of using quarterly ports for building .pbi's they were using HEAD, which means newest version of apps but a library dependencies nightmare.
The concept was good but the implementation was so bad. Instead of focusing on something that was worth they spend man power on inventing a "BSD Desktop", Lumina. Now most likely it will be a dead project, just like PC-BSD (TrueOS), bla,bla,bla is. In won't get to long and those two morons will kill FreeNAS too.
 
FreeNAS is TrueNAS and that is also based on Linux (read will be Linux based - i.e. refer to what happened to Project Trident). It also suited IX from a business perspective when ZFS on FreeBSD and ZoL merged - must have made it easier to jump ship. Business is business.
 
cynwulf said:
FreeNAS is TrueNAS and that is also based on Linux (read will be Linux based - i.e. refer to what happened to Project Trident). It also suited IX from a business perspective when ZFS on FreeBSD and ZoL merged - must have made it easier to jump ship. Business is business.
Click to expand...
NAS4Free (now Xigmanas) is the real name of the actual project that was once FreeNAS.
Xigmanas is doing well, and I use it everywhere.
 
cynwulf said:
FreeNAS is TrueNAS and that is also based on Linux (read will be Linux based - i.e. refer to what happened to Project Trident). It also suited IX from a business perspective when ZFS on FreeBSD and ZoL merged - must have made it easier to jump ship. Business is business.
Click to expand...
I'm not so sure. iXSystems has a large legacy with FreeBSD (they even evolved from BSDi). Their skillset is likely to cause them to remain with FreeBSD being the operating system behind TrueNAS.

As for Project Trident, this was a friendly fork of TrueOS's UI system and they were welcome to use whatever platform underneath they wanted. It was not run by the commercial iX Systems.
 
Last night was the first time I've ever built a FreeBSD desktop from ground up using pkg instead of ports.

I taught myself to use ports when I didn't care for the PC-BSD .pbi Push Button Installer sometime after joining in 2005. Since then I've only used pkg a handful of times on the rare occasion to get a program like graphics/gimp running that I use often. So this was a new experience for me.

I didn't want to stress my IBM Thinkpad T43 compiling ports so thought it best pkg used this time. However, I still downloaded a snapshot of the ports tree so I could maintain full control. When I ran # pkg audit -F it bootstrapped like it says you can do in the Handbook by issuing # /usr/sbin/pkg.

From then on it could not have been automated in a more orderly manner or easier to install every program I usually install by ports and a lot quicker. The only difference being I couldn't set options like to have security/nmap scan for ports as part of # rkhunter --checkall when installing security/rkhunter by pkg.

I checked # pkg audit -F one final time before exiting the root terminal and invoking $ startx for the first time. It showed pkg had willingly installed a vulnerable version of graphics/jasper, and we can't have that:

# cd /usr/ports/graphics/jasper
# make deinstall clean
# make install clean

So I fixed it using ports, it's still running and all is well.

What took longest was configuring of system files, programs and the desktop like I wanted it. Not installation of the base system or 3rd party programs.
 
You must log in or register to reply here.
Back
Top