It seems that pkg is still new enough that people have not yet settled on workarounds for unsupported/not-recommended hacks for when you need to work outside the box.
I have a simple scenario where almost every package is built by poudriere and hosts are generally running 100% of their third-party software from our own poudriere repository. This generally works great. I do however have a single host that runs a heavily hacked-up qmail install. It will likely run this exact patched-up mess until it dies. Everything else on the host comes from our poudriere repository, including some things that depend on Qmail being installed (vpopmail, qmailadmin, qmhandle, etc.). When the host was not yet live, I worked around this by letting pkg install a generic qmail, then running pkg lock on qmail, and then installing my local qmail binaries on top of the pkg-installed qmail.
That worked for a long time - I'd tricked the package manager into thinking a dependency was installed and the lock prevented mistakes that might overwrite my local qmail. Now I see that someone has decided to remove the qmail port and replace it with netqmail and pkg won't let me proceed with upgrading anything that depends on qmail until I let it swap netqmail for qmail.
I can do something ugly like tarring up my qmail install, letting pkg do its thing and then untarring my qmail install over the pkg version again, but I'd really like to know if there are some other options here, mainly to try and learn about what facilities are available with pkg for weird one-off hacks that I may have missed.
How do others make pkg bend to their will (no matter how ill-advised that is) in cases like this?
I have a simple scenario where almost every package is built by poudriere and hosts are generally running 100% of their third-party software from our own poudriere repository. This generally works great. I do however have a single host that runs a heavily hacked-up qmail install. It will likely run this exact patched-up mess until it dies. Everything else on the host comes from our poudriere repository, including some things that depend on Qmail being installed (vpopmail, qmailadmin, qmhandle, etc.). When the host was not yet live, I worked around this by letting pkg install a generic qmail, then running pkg lock on qmail, and then installing my local qmail binaries on top of the pkg-installed qmail.
That worked for a long time - I'd tricked the package manager into thinking a dependency was installed and the lock prevented mistakes that might overwrite my local qmail. Now I see that someone has decided to remove the qmail port and replace it with netqmail and pkg won't let me proceed with upgrading anything that depends on qmail until I let it swap netqmail for qmail.
I can do something ugly like tarring up my qmail install, letting pkg do its thing and then untarring my qmail install over the pkg version again, but I'd really like to know if there are some other options here, mainly to try and learn about what facilities are available with pkg for weird one-off hacks that I may have missed.
How do others make pkg bend to their will (no matter how ill-advised that is) in cases like this?
