How do I delete a package from the system leaving the installed files in place

scotia

scotia

Hi,

I installed package "foo" and later starting using the upstream of "foo" to upgrade it rather than wait for ports to catch up.

How can I remove the "foo" package without actually deleting the files (that have since been upgraded manually)?

I want to do this lest I downgrade doing a ports rebuild after a major OS version update.

Many thanks in advance,
Scott
 
If I understand your question then
Code: 
 pkg delete -f foo
will remove foo and leave all other packages. I'm guessing you mean that you find that pkg delete foo will also remove several other packages that depend upon it.

Another Scott :)
 
Hi,

no - I want to leave the files that were installed as part of "foo" intact (let's say it has no dependencies). I just want to remove "foo" from the package database.

Thanks
 
Hi,
scotia said:
I installed package "foo" and later starting using the upstream of "foo" to upgrade it rather than wait for ports to catch up.

How can I remove the "foo" package without actually deleting the files (that have since been upgraded manually)?

I want to do this lest I downgrade doing a ports rebuild after a major OS version update.

Many thanks in advance,
Scott
Click to expand...
You could prevent it from being altered by the package system with pkg lock foo
 
This looks like a recipe for disaster to me, depending on the package. Why not remove the package (and its files), re-install your updated version somewhere and leave things there until the package catches up?
 
ShelLuser said:
Why not remove the package
Click to expand...
It has no dependencies nor is it a dependency and rather than stopping the service, deleting the package, reinstalling from upstream, restarting the service - I thought I'd ask if I could just remove the package from the DB.
In this case there's no disaster caused by doing so (that I can see). The system would just forget it's still there.
 
I had to do this, and so worked it out for myself. Pretty easy, but requires editing the package database directly using sqlite:
sudo sqlite3 /var/db/pkg/local.sqlite



Bash: 
sudo sqlite3 /var/db/pkg/local.sqlite
sqlite>  select id,name from packages where name like '%pkgname%';
1897|pkgname
# Note the numerical id of the package, here 1897. Then use it
delete from files where package_id=1897;
delete from packages where id=1897;
sqlite> ^D

Now the packaging system will have forgotten about that package.
 
scotia said:
… remove the "foo" package without actually deleting the files …
Click to expand...

I sometimes wish for this, for reasons unlike the example in your post.

I searched GitHub a few months ago, the closest I could find was freebsd/pkg issue 311.

(Side note: the link to pkg-plugin-zfssnap is redundant, I could not find a modern equivalent plugin for pkg.)

Use case​

  1. Use freebsd-update(8) to attempt an update or upgrade
  2. as a result, encounter an issue that will be relatively time-consuming and/or difficult to resolve using traditional methods
  3. break from tradition
  4. use pkg-add(8) to resolve the issue quickly, and with ease.
After resolving the issue, then either:

a) switch to pkgbase (and cease using freebsd-update); or

b) continue using freebsd-update for as long as you like (or until its removal from FreeBSD).

With scenario (b) it may be desirable to effectively deregister a package for a base file.


Think bubbles … the case where I used official Project packages for so long, I forgot about archaic use of alpha.pkgbase.live when the base was inferior to 14.0 … VirtualBox? Discord.
 
Depending on how simple the package is in terms of dependencies, rather than lieve it in place (potentially running the risk of a file conflict), can you just grab the package, extract it manually to i.e /opt/<software>?

I created pkg_bundle on OpenBSD for this specific task, but due to lack of interest, I never ported it to FreeBSD. That said, it is time consuming, but not too hard to do manually on FreeBSD. Use pkg-fetch(8) to grab all the tarballs and extract them; finally apply some random scripts to set PATH/LD_LIBRARY_PATH, etc.

Note that the "correct" way to do this is probably create a standalone Jail with your ad-hoc package installed in. That way it can't conflict with the files managed by the OS package manager.
 
You must log in or register to reply here.
Back
Top