Open grembo opened 8 years ago
pkg versions involved:
Before update: 1.8.7_1 After update: 1.8.7_3
I don't really see what the problem is.
You told pkg: Please install libressl pkg answered: hey, you already have it, let's upgrade it. You said: ok
Running pkg install to upgrade a port is a very bad idea.
To upgrade your system, always run "pkg upgrade". Never do partial upgrades.
The problem is that an experienced admin (not FreeBSD in particular) did something that seemed perfectly normal and ended up with a broken system. I usually do pkg upgrade
for exactly that reason, as I'm used to pkg, but there is nothing in the documentation or the program warning one about this (see man pkg-install
).
Arguably the behavior of pkg install
should be changed then to say libressl already installed
. To prevent people from doing selective upgrades like this. Granted I have done them in the past in certain circumstances, but this is a bad one.
Maybe require -f to selectively upgrade a pkg like this?
It should be possible to detect the potential breakage and refuse the update unless -f
is given on the command line.
Since it is aware of the shared libraries this should be doable.
I don't really see what the problem is.
You told pkg: Please install libressl pkg answered: hey, you already have it, let's upgrade it. You said: ok
Running pkg install to upgrade a port is a very bad idea.
@mat813 The problem is in bold face.
I'm well aware of how to use pkg, but I feel like we're setting people up for failure - this is not the first time I had to support an experienced colleague who broke their system using pkg by accident.
Yes, pkg should be smarter and lead people in the right direction.
I just got feedback that pkg install
wasn't used, but pkg upgrade libressl
, which makes the whole thing more interesting, since pkg-upgrade(8) says:
Where a package on the work list supplies a shared library, and that library has been updated, all packages requiring that shared library will also be added to the work list as reinstallation jobs.
pkg upgrade foo
should never have existed, using it is like foot-shooting while free-falling without a chute.
I actually wasn't aware it existed, that's why I assumed pkg install
was used.
But it's in there, in a release version that ships with the OS as the official tool for doing these things and the official documentation states that's how it's used and claims that it will do something it doesn't (at least not reliably).
I believe at one point the idea was to make 'pkg install' and 'pkg upgrade' pretty much synonymous, or at least merge update.c and install.c in the sources and eliminate a lot of duplication between those two files.
Agreed that we need to fix the documentation so that it makes it very clear that trying to cherry pick updates is not at all recommended. It should still be possible though, as it can be a life saver.
Well since we know the shared libraries, it is possible ..
yes it should be possible actually it is mostly done, it is missing adding some reverse deps to the plan
And doing that would also actually fix plenty of situation users can end up having issues with
We just encountered the following problem:
System based on 2016Q3 running stunnel-5.33,1 and libressl-2.3.6.
After switching to 2016Q4, the admin ran:
pkg install libressl
Which kindly offers an update to libressl 2.4.3:
Afterwards, stunnel is broken, as it depends on libcrypto.so.37 and libssl.so.38, something pkg was aware of before of the update:
I would expect pkg to warn about the shared library change or offer the new version of stunnel (which was available in the new repo).
After running
pkg upgrade
to pick up new versions of all packages, things are ok again:This feels wrong to me - updating individual packages shouldn't butcher packages dependent on them.
-m