PKG is a total disaster

B

Barney

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.
 
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.
 
Barney said:
I haven't used my Freebsd 12.1 in a few months
Click to expand...
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;
Click to expand...
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,
Click to expand...
It is. But not if you insist on doing everything your own way. Work with the system, not against it.
 
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.
 
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.
Click to expand...
 
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.
 
Last edited:
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.
 
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?)
 
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.
 
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.
 
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:
Code: 
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.
 
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.
Click to expand...
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
 
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.
Click to expand...

Standard answer of Sysadmin #1 : Its working here just fine.
 
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.
 
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.
Click to expand...
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.
 
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.
 
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.
Click to expand...
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.
 
ShelLuser said:
That previous system was the package management which was used on Sun Solaris
Click to expand...
Could you elaborate more about this? Does that mean the classic pkg_* utilities shared by all BSDs originated from Solaris? Thanks.
 
also-ran said:
Does that mean the classic pkg_* utilities shared by all BSDs originated from Solaris?
Click to expand...
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.
 
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.
Click to expand...

But I didn't want to be rude about it.
 
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.
Click to expand...
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?
 
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 said:
I also though that until I learned (here from who?) SunOS is SysV not BSD family.

See above? (SVR4 := System V release 4)
Click to expand...
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).
 
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.
 
You must log in or register to reply here.
Back
Top