How to pin a "pkgin" package, what is the right way to deploy my own packages?
This post transcribes some emails I sent to SmartOS mailing list:
My initial email:
Message-ID: <d50150d8-b863-3886-89d7-f2ae156610a2@jcea.es>
Date: Mon, 4 Mar 2024 03:02:31 +0100
To: smartos-discuss <smartos-discuss@lists.smartos.org>
From: Jesus Cea <jcea@jcea.es>
Subject: [smartos-discuss] How to pin a "pkgin" package, what
is the right way to deploy my own packages?
I compiled an Apache server package myself because I need some
special compilations. I used the pkgsrc-tls zone image. In
order to avoid automatic updates, I modified the package
version from "2.4.58" to "2.4.589" (I added a 9 at the end). I
naively considered that since my version is higher, it would
override system package.
I did that change in the Makefile.
I manually installed the package with "pkg_add". So good so
far.
Then, I installed stock pkgsrc package
"py312-ap24-mod_wsgi-4.9.4". The dependencies of that package
are:
"""
[root@TEST ~]# pkgin show-deps py312-ap24-mod_wsgi-4.9.4
direct dependencies for py312-ap24-mod_wsgi-4.9.4
py312-setuptools-[0-9]*
apache>=2.4.58nb1<2.5
gcc13-libs>=13.2.0
python312>=3.12.0
"""
Since dependencies list "apache>=2.4.58nb1<2.5", I would
guess that my "apache-2.4.589" would fit the bill. But pkgin
"refreshes" package system "apache-2.4.58nb1" (not actually
installed!), replacing my package "apache-2.4.589".
So my questions are:
* What would be the right way to compile/install my own
packages shadowing "pkgin" packages, in order to avoid SmartOS
to mess with them when "pkgin install" some other package or,
worse "pkgin upgrade". Yes, I know that this have security
implications, I deal with them myself for my packages.
* Sometimes installing a package does a "refresh" of an
already installed package. Apparently, this uninstall and
reinstall the package. In this particular case, that "refresh"
uninstall my package and install the system package. What is
the point of this "refresh"? What are the conditions that
trigger that action?.
Any advice? Best practices?
Thanks!
PS: My packages are not signed (yet), I disabled (temporary)
signature verification, if that is something important.
After a few hours, Jonathan Perkin <jperkin@mnx.io> provided this useful reply:
Date: Mon, 4 Mar 2024 09:18:21 +0000 From: Jonathan Perkin <jperkin@mnx.io> To: smartos-discuss <smartos-discuss@lists.smartos.org> Subject: Re: [smartos-discuss] How to pin a "pkgin" package, what is the right way to deploy my own packages? Message-ID: <ZeWR3Y9NO-ggG_Yu@mnx.io> References: <d50150d8-b863-3886-89d7-f2ae156610a2@jcea.es> * On 2024-03-04 at 02:04 GMT, Jesus Cea wrote: >* What would be the right way to compile/install my own >packages shadowing "pkgin" packages, in order to avoid >SmartOS to mess with them when "pkgin install" some other >package or, worse "pkgin upgrade". Yes, I know that this have >security implications, I deal with them myself for my >packages. pkgin keys packages based on their PKGPATH, i.e. in the case of apache it'll be www/apache24. If your custom package is built in that same directory, then regardless of the version, pkgin will treat it as being the same. In order to stop that happening, create a separate directory in pkgsrc for your custom packages and copy the apache24 directory there, for example local/apache24. You can also then revert any version numbering changes and just use the same as the www/apache24 package. Ideally have your own git repository for custom packages, for example the packages under pkgsrc/extra in our tree come from https://github.com/TritonDataCenter/pkgsrc-extra which is added as a git submodule. >* Sometimes installing a package does a "refresh" of an >already installed package. Apparently, this uninstall and >reinstall the package. In this particular case, that >"refresh" uninstall my package and install the system >package. What is the point of this "refresh"? What are the >conditions that trigger that action?. Refresh happens if the remote package BUILD_DATE is newer than what is installed. This happens quite frequently, as pkgsrc will rebuild a package if any of its dependencies have changed, but this avoids many classes of severely unpleasant bugs. One thing to note is that this will happen regardless of version, as there are some occasions where the version will go backwards (e.g. we found a critical bug in the newer software and had to revert back to a previous release), which is why your modification of the version didn't really do anything. Cheers,