Requested by a user deploying printer packages: there is currently no way to parameterize a pkgsinfo, so packages that differ only in a few values have to be maintained as full copies.
The shape of the problem
Printer deployment is the motivating case. Each printer needs an otherwise identical pkgsinfo where only a handful of values change — printer name, device address, port name, driver name — repeated across installcheck_script, postinstall_script, postuninstall_script, and uninstallcheck_script within the same file. Today that means one hand-duplicated pkgsinfo per printer, with the same literal repeated four or five times inside each. A site with a dozen printers maintains a dozen near-identical files, and a driver revision is a dozen edits.
The same shape shows up for site-specific config packages, per-lab variants, and anything where one package template is instantiated per location.
Sketch
Something like a top-level variables: block, substituted into scalars and script bodies at import or catalog time:
variables:
printer_name: Front Office
printer_ip: 10.0.0.10
driver_name: Generic PCL6
name: Printer-FrontOffice
display_name: "${printer_name}"
postinstall_script: |
Add-PrinterPort -Name "IP_${printer_ip}" -PrinterHostAddress "${printer_ip}"
Add-Printer -Name "${printer_name}" -DriverName "${driver_name}" -PortName "IP_${printer_ip}"
postuninstall_script: |
Remove-Printer -Name "${printer_name}"Open questions worth settling before implementing:
- Where substitution happens. Import/catalog time keeps the client dumb and means catalogs stay fully-resolved (so no client change and no version skew). Client-side would allow machine-scoped values but widens the blast radius.
- Whether values can come from the client — a manifest-level or conditional-item value would cover "same package, different value per site", which is arguably the stronger version of this request given the three-tenant deployments this user is running.
- Delimiter choice.
$VAR is unsafe here: pkgsinfo script bodies are PowerShell, which uses $ for its own variables. A previous bare-$VAR substitution pass in cimipkg corrupted embedded scripts, so any syntax adopted must be one PowerShell never produces — ${{ }}, @@VAR@@, or similar — and substitution must be explicitly scoped, not a blind string replace over script bodies.
Related
A per-printer package is also the case in #90 — script-based removal — so both need to work before this workflow is properly supported.
Requested by a user deploying printer packages: there is currently no way to parameterize a pkgsinfo, so packages that differ only in a few values have to be maintained as full copies.
The shape of the problem
Printer deployment is the motivating case. Each printer needs an otherwise identical pkgsinfo where only a handful of values change — printer name, device address, port name, driver name — repeated across
installcheck_script,postinstall_script,postuninstall_script, anduninstallcheck_scriptwithin the same file. Today that means one hand-duplicated pkgsinfo per printer, with the same literal repeated four or five times inside each. A site with a dozen printers maintains a dozen near-identical files, and a driver revision is a dozen edits.The same shape shows up for site-specific config packages, per-lab variants, and anything where one package template is instantiated per location.
Sketch
Something like a top-level
variables:block, substituted into scalars and script bodies at import or catalog time:Open questions worth settling before implementing:
$VARis unsafe here: pkgsinfo script bodies are PowerShell, which uses$for its own variables. A previous bare-$VARsubstitution pass incimipkgcorrupted embedded scripts, so any syntax adopted must be one PowerShell never produces —${{ }},@@VAR@@, or similar — and substitution must be explicitly scoped, not a blind string replace over script bodies.Related
A per-printer package is also the case in #90 — script-based removal — so both need to work before this workflow is properly supported.