# PKG is a total disaster



## Barney (Mar 3, 2021)

whoever conceptualized this pkg management system needs to be brought out to the shed. I haven't used my Freebsd 12.1 in a few months, and I can't install a simple library without having to re-install every application on the planet that's a few weeks out of date. And the system is stupid; for example my Perl was a few minutes out of date, so it insisted on installing Perl 5; it installs all of the dependencies before telling me I already have last weeks version of PERL and I'll have to deinstall it and re-install PERL to load the stupid little library I wanted to use. My gmake was 45 seconds old so I had to re-install this. 1/2 hour later I still have no idea how close or far I am from using this library, which should be able to just be plopped into /usr/local/lib and used like with any other reasonable OS.

Pkg is supposed to make things easy, but it makes everything more difficult. It's a total failure as a concept.

FreeBSD is becoming everything I hate about linux.


----------



## diizzy (Mar 3, 2021)

You can force installation of a single package but don't blame anyone if things break as FreeBSD does utilize shared libraries which pretty much any other distribution also does.
12.1 is also EOL and unsupported so you're on your own in that regard, https://www.freebsd.org/security/
Unless there's a security issue packages in quarterly branch rarely changes.


----------



## SirDice (Mar 3, 2021)

Barney said:


> I haven't used my Freebsd 12.1 in a few months


FreeBSD 12.1 is EoL. 



Barney said:


> for example my Perl was a few minutes out of date, so it insisted on installing Perl 5;


This is unlikely. Either that or you insisted on installing a different version than the default. The default Perl version is 5.32 at the moment. 


Barney said:


> Pkg is supposed to make things easy,


It is. But not if you insist on doing _everything_ your own way. Work _with_ the system, not _against_ it.


----------



## CuatroTorres (Mar 3, 2021)

It would be better to show pkg outputs, package versions and warnings to get a better idea, perhaps with the intention of reproducing a similar scene.


----------



## Barney (Mar 3, 2021)

> This was more a rant than a request for help. I'm not going to spend the day trying to resolve this. It will take less time to install a completely new OS. It's a total disaster. You fix one thing and something else is broken.


----------



## Mjölnir (Mar 3, 2021)

It's perfectly human to let steam off occasionally...   Don't let that fsck(8)ing _thang_ kill your patience.  Keep on studying the Handbook like you did up to here, and take ZFS snapshots frequently (e.g. sysutils/zfstools or sysutils/zfsnap2 via sysutils/anacron).  FreeBSD is harsh to newbies, but cozy to the wizzards.  The learning curve is not steep.  The more you get after it, how it all fits together, the more you'll like it.


----------



## richardtoohey2 (Mar 3, 2021)

Good luck finding the Perfect OS (TM) with Perfect Ports (TM) and Untroubled Upgrades (TM).

Don't think I've found an OS/device that doesn't need upgrading at least once a week these days, and often you are left with issues - whether OpenBSD, FreeBSD, MacOS X (endless Bluetooth troubles on Big Sur), Linux Mint (major upgrade process is a bit unfriendly, and I've ended up with a few broken packages occasionally with the Update Manager), etc., etc.  Android & iOS not so many issues, and Windows fairly stable (but then that's just the OS upgrade, it doesn't upgrade any ports/packages).

And the constant rate of change/churn with bits added/removed often for no apparent gain.


----------



## zirias@ (Mar 3, 2021)

I wonder whether it is a good or a bad thing about this forum that posts like this actually get responses 

And I'm lacking imagination as to what exactly you have to do to get to this sort of complaints.

Of course, upgrading packages for FreeBSD 12 on the EOL 12.1-RELEASE will break *something*, but it doesn't look like it's about that (next rant already scheduled?)


----------



## trev (Mar 4, 2021)

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.


----------



## zirias@ (Mar 4, 2021)

It will only ever install additional packages or remove packages if changed dependencies/conflicts force it to do so. If you keep the default (using the quarterly repository), this will only happen 4 times a year. If you use latest and are unlucky enough to need packages that change a lot, including dependencies, just make sure to `pkg upgrade` often enough to limit the impact. Using ports won't change anything about this, except if you happen to disable exactly that option that's responsible for the change in dependencies.


----------



## SirDice (Mar 4, 2021)

Don't forget to run `pkg autoremove` regularly too. That will clean up old, unused, dependencies. My typical upgrade/update cycle is something like this:

```
pkg update  # not strictly necessary, is usually automatically done before a pkg upgrade
pkg upgrade
pkg autoremove
pkg clean
```
The last pkg-clean(8) will clean up /var/cache/pkg/, it can accumulate quite a lot over a long period of upgrades and installs. I actually use `pkg clean -a` as I have my own repositories and have no need for the local cache, but if your internet connection is a bit slow (or the repository servers) you might want to keep the local cache.


----------



## jb_fvwm2 (Mar 5, 2021)

Barney said:


> whoever conceptualized this pkg management system needs to be brought out to the shed. I haven't used my Freebsd 12.1 in a few months, and I can't install a simple library without having to re-install every application on the planet that's a few weeks out of date. And the system is stupid; for example my Perl was a few minutes out of date, so it insisted on installing Perl 5; it installs all of the dependencies before telling me I already have last weeks version of PERL and I'll have to deinstall it and re-install PERL to load the stupid little library I wanted to use. My gmake was 45 seconds old so I had to re-install this. 1/2 hour later I still have no idea how close or far I am from using this library, which should be able to just be plopped into /usr/local/lib and used like with any other reasonable OS.
> 
> Pkg is supposed to make things easy, but it makes everything more difficult. It's a total failure as a concept.
> 
> FreeBSD is becoming everything I hate about linux.


Having become accustomed to pkg [ at first not easy ] I continue to
think two systems should/could be enabled in parallel on a system...
especially for production machines... the pkg system AND the /var/db/pkg
directories, for in case urgent pkg failure recovery using portmaster which
seems to, or might, still use the latter, or portupgrade, or one could script
one's own...
for instance directory: yell-1.1 with
+COMMENT [ the short description, from the Makefile ]
+CONTENTS [this one specific for the port upgrades ]
+DESC [ just the pkg-descr ]
+MTREE_DIRS [ this one works with the one above  ]
files within it


----------



## tyson (Mar 5, 2021)

Barney said:


> whoever conceptualized this pkg management system needs to be brought out to the shed. I haven't used my Freebsd 12.1 in a few months, and I can't install a simple library without having to re-install every application on the planet that's a few weeks out of date. And the system is stupid; for example my Perl was a few minutes out of date, so it insisted on installing Perl 5; it installs all of the dependencies before telling me I already have last weeks version of PERL and I'll have to deinstall it and re-install PERL to load the stupid little library I wanted to use. My gmake was 45 seconds old so I had to re-install this. 1/2 hour later I still have no idea how close or far I am from using this library, which should be able to just be plopped into /usr/local/lib and used like with any other reasonable OS.
> 
> Pkg is supposed to make things easy, but it makes everything more difficult. It's a total failure as a concept.
> 
> FreeBSD is becoming everything I hate about linux.



Standard answer of Sysadmin #1 : Its working here just fine.


----------



## kpedersen (Mar 5, 2021)

I am still not a fan of pkgng but that ship has sailed.
I am also not convinced that the original system would have solved Barney's problem either.

Perhaps install packages in a Jail and then blow the whole thing away and install from scratch rather than updating? For my uses I can get away with updating every ~6 months (and I do a whole wipe) but otherwise I would probably give that a shot.


----------



## ShelLuser (Mar 5, 2021)

kpedersen said:


> I am still not a fan of pkgng but that ship has sailed.
> I am also not convinced that the original system would have solved Barney's problem either.


That previous system was the package management which was used on Sun Solaris, which was my all time favorite Unix environment at one time (long before the Oracle disaster). I've always enjoyed working with it myself, but in the end it was even more sparse than pkgng is. Solely basing myself on the rant I don't think the OP would even have managed to keep their system up to date at all.

Because if you compare the Solaris tools with pkgng then it's a difference of night and day. It's very well structured, provides solid documentation, has a really logical way of working and in the end it's both user friendly _and_ quite versatile.

IMO only tools blame their tools.


----------



## SirDice (Mar 5, 2021)

That why I mentioned that one has to work _with_ the tools, not _against_ them. Many people that are struggling with pkg(8) are forcing it do something it's not meant to be doing. Then get frustrated because it doesn't work the way they want. But if you sit down, look at it from another perspective, you can make it do almost anything. As with many other FreeBSD related things, it works best if you let the system do the work. Don't try to outsmart it, it usually backfires. Most of the time when I can't get something to work it's because _I_ did something wrong.


----------



## kpedersen (Mar 5, 2021)

SirDice said:


> As with many other FreeBSD related things, it works best if you let the system do the work. Don't try to outsmart it, it usually backfires.


I am certainly at fault for occasionally trying to misuse the software. And yes, it indeed does usually backfire on me 

Sometimes though if letting the system do the work involves relying on a 3rd party server, I am never entirely satisfied with this. Luckily with FreeBSD that is not really the case. Or at least I can bend the tools away from that.
There is a really thin line between convenience and yet another service outside of our control. Far too many package managers make us very reliant on infrastructure that isn't really ours.

The most close to "package manager as a service" I have seen is actually Oracle's Solaris 11+ IPS. Helped developed by the late Ian Murdock which interestingly leads to Debian's apt which I also find very difficult to pull away from central servers. Perhaps Oracle was looking to leverage this dependence to monetize. Who knows.


----------



## Deleted member 66267 (Mar 6, 2021)

ShelLuser said:


> That previous system was the package management which was used on Sun Solaris


Could you elaborate more about this? Does that mean the classic pkg_* utilities shared by all BSDs originated from Solaris? Thanks.


----------



## ShelLuser (Mar 6, 2021)

also-ran said:


> Does that mean the classic pkg_* utilities shared by all BSDs originated from Solaris?


To be honest I never bothered to look into their exact origin but based on what I've read (and experienced) back in the day that's exactly what happened. Fun thing is that I actually moved from Sun Solaris 10/x86 to FreeBSD when I started out with this marvelous adventure and I didn't have to re-learn anything about ZFS (this also came from Solaris), the firewall (I obviously used IPF back in the day, the Solaris firewall) and the package management system...

There are several parts of FreeBSD which found their origin in Sun Solaris.


----------



## Deleted member 30996 (Mar 7, 2021)

Well I was thinking about converting my treasured IBM T-43 from an older version of OpenBSD to FreeBSD using pkg, only because I love it so and don't want to put it through the stress of compiling ports. 

I wondered if there might be a problem with pkg when I saw this thread but after reading the first post OP made, I knew everything would be alright. 



SirDice said:


> But not if you insist on doing _everything_ your own way. Work _with_ the system, not _against_ it.



But I didn't want to be rude about it.


----------



## Deleted member 66267 (Mar 8, 2021)

ShelLuser said:


> To be honest I never bothered to look into their exact origin but based on what I've read (and experienced) back in the day that's exactly what happened.


Seemed to be originated from SunOS, which is BSD based before it became Solaris.
But if it's so why the Solaris guys keep calling it the SVR4 package manager I wonder?


----------



## kpedersen (Mar 8, 2021)

Solaris 11 still actually has `pkgadd` installed and supported. Most third party repos for Solaris (i.e OpenCSW) still use it.

I imagine for internal deployments, many companies still keep to the pkgadd approach because it is so much easier to build / maintain than the very infrastructure heavy IPS stuff.


----------



## Mjölnir (Mar 8, 2021)

also-ran said:


> Seemed to be originated from SunOS, which is BSD based before it became Solaris.


I also though that until I learned (here from who?) SunOS is SysV not BSD family.


also-ran said:


> But if it's so why the Solaris guys keep calling it the SVR4 package manager I wonder?


See above? (SVR4 := System V release 4)


----------



## Minbari (Mar 8, 2021)

Mjölnir said:


> I also though that until I learned (here from who?) SunOS is SysV not BSD family.
> 
> See above? (SVR4 := System V release 4)


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.

OP. If you don't like ports-mgmt/pkg, sysutils/pacman is in ports. (pacman=Arch Linux package manager).


----------



## tuaris (Mar 9, 2021)

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:

1. Storage got cheap
2. Package management systems

In case that was too subtle...

The way I understand it... the current approach came to be out of necessity, due to the lack of the two points above.  Shared libraries were used prevent having multiple copies of the same thing installed in diffent places.  This would reduce storage needs and make it easier to update a library (for whatever reason).

With today's package management systems, the process and effort needed to update a library is the same no matter how it's installed.  As far as storage goes, it's not a concern.


----------



## tuaris (Mar 9, 2021)

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.


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.


----------



## richardtoohey2 (Mar 9, 2021)

tuaris said:


> shift towards non-shared library versions of ports


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.


----------



## tuaris (Mar 9, 2021)

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.


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.


----------



## richardtoohey2 (Mar 9, 2021)

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!


----------



## tuaris (Mar 9, 2021)

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,


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.


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.


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.


----------



## Mjölnir (Mar 9, 2021)

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.


----------



## kpedersen (Mar 9, 2021)

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.


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.


----------



## KonkyBonky (Mar 10, 2021)

tuaris said:


> non-shared library versions of ports? (for non-embedded)


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.


----------



## byrnejb (Mar 10, 2021)

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


----------



## BostonBSD (Mar 10, 2021)

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


----------



## Minbari (Mar 10, 2021)

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


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.


----------



## cynwulf (Mar 11, 2021)

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.


----------



## tuaris (Mar 11, 2021)

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.


NAS4Free (now Xigmanas) is the real name of the actual project that was once FreeNAS.
Xigmanas is doing well, and I use it everywhere.


----------



## kpedersen (Mar 11, 2021)

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.


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.


----------



## Deleted member 30996 (Mar 15, 2021)

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.


----------



## SirDice (Mar 15, 2021)

Trihexagonal said:


> It showed pkg had willingly installed a vulnerable version of graphics/jasper, and we can't have that:


Looks like someone forgot to merge that update to the quarterly branch too.




__





						[ports] Revision 567117
					






					svnweb.freebsd.org


----------

