pkg lock

[Polytropon]

On Mon, 9 Sep 2019 09:21:13 -0600, @lbutlr wrote:
> If I want to prevent pkg update from overwriting a package I built
> from ports, I need to issue a pkg lock <port> first, then if I want
> to rebuild it with postmaster I pkg unlock <port>, rebuild/update
> the port, and then lock the port again, yes?

That is the correct order. It also applies if you use pkg to update
your software. Rule: "lock around update step". :-)



> And there is no one-step way to say via flags or something, unlock,
> rebuild, then lock at once?

Not that I'm aware of. I (ab)use a custom Makefile for this task:

1. lock the custom ports
2. perform a pkg upgrade (typically uses monthly repository)
3. obtain current ports tree
4. unlock the custom ports
5. run "make deinstall" and "make reinstall" for custom ports
6. hope that everything went well ;-)

This is on systems that have few (!) ports with custom options, and
use pkg-based installing and updating (binary packages, no ports built
for "normal" things).



> Also, is there anyway to tell what has been installed via ports and
> what has been installed via pkg? Or better, what has been installed
> with custom options that differ from the pkg versions?

Technically not, because if you install something using portmaster
or plain "make install", what happens is that a "pkg-kind of package"
is built, and _this_ package then is installed. So to pkg, it's just
another package. However, you could compare the options used to build
a specific port (standard values) and compare them to the options you
used to build it (custom values). As far as I know, this task is not
automated.





-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...