Re: removing a pkg from pkg database without deleting the pkg itself
- In reply to: Matthew Seaman : "Re: removing a pkg from pkg database without deleting the pkg itself"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 04 Apr 2022 18:42:34 UTC
Am 04.04.22 um 18:38 schrieb Matthew Seaman: > On 04/04/2022 16:27, tech-lists wrote: >> On Mon, Apr 04, 2022 at 03:35:16PM +0200, Stefan Esser wrote: >>> Am 04.04.22 um 15:26 schrieb tech-lists: >>>> Hi, >>>> >>>> I'd like to remove a pkg entry from the database so it's not managed by pkg. >>> >>> The simplest way to exclude an installed package from being managed >>> by pkg is to use "pkg lock": >>> >>> # pkg lock -y <pkgname> >>> >>> See "man pkg-lock" for more details. >> >> That will work for a time, but won't it stop other packages linked to it from >> being updated? If this package is installed as a dependency of some other package, you can expect inconsistencies and conflicting dependencies to arise over time. >> The packages in question are nextcloud and drupal. I have used "pkg lock" for NextCloud and it worked for me ... >> The other thing is that even with pkg lock, I seem to recollect it'll still >> show up in packages-that- >> need-upgrading in the daily cronjob. I might be wrong about that though. > > pkg(8) doesn't really have a concept of giving up management of a package that > it originally installed. Not only that, but pkg does not manage individual packages, but wants to have an intact dependency graph. Only "loosely" connected packages can be excluded from that graph without issues cropping up over time. In case of e.g. NextCloud you can manage the PHP interpreter and general PHP modules with pkg and the nextcloud sub-tree independently using the update procedure provided by NextCloud. > What you could do is use 'pkg info' to generate a list of the files installed > by the package. Feed that into tar(1) to create a backup, then use pkg(8) to > delete the package and tar to recover the files from your backup. There will > be a short service outage while you do that: if that's not acceptable then you > can probably adapt the procedure by using tar(1) or similar to copy the package > files to an alternate filesystem location, making whatever config changes you > need to in your webserver and application config to serve the site from the new > location, and then deleting the original package. You can fetch the package with "pkg fetch" (or may already have a copy in /var/cache/pkg) and directly extract from that file, without prior installation via the pkg command. You have to check for any install scripts, but these exist in only a small fraction of the ports. The just go to the root directory and extract all files with paths that start with /usr/local: # tar xf /var/cache/pkg/<pkgfile> /usr/local This should work for most packages, but there might be cases where the more complex method suggested by Matthew gives slightly better results. Regards, STefan