Issue #17438 has been updated by C L.
Assignee changed from C L to eric sorenson
Hi Eric. Thanks for your response.
I understand where you are coming from with widely used packaging systems like
RPM, DPKG, et al. Those packaging systems, when recompiling from the package
source, does indeed allow one to change/increment the package version for
building the binary package (for debian, the `dch` tool is used to achieve
this).
Other packaging systems do not necessarily support such end-user extended
versioning schemes.
My current pain is with FreeBSD and the ports collection where the version
number can not be easily changed by an end-user when recompiling from package
source code (FreeBSD calls this a port). The version numbering is maintained
exclusively by the FreeBSD ports tree maintainers. The package source can have
a number of knobs to enable/disable features when building a binary package.
When the binary package is built, it will be installed as the same version as
the source code from which it was built, irrespective of what knobs have been
twiddled.
Let us take a simple example. Suppose I have built `sqlite3` version 3.7.14.1
from ports without changing any of the default enabled feature set. Puppet is
used to deploy and install the built binary package to many machines. Later, a
need to enable a feature in sqlite3 is required and re-deployed. The feature
has been defaulted to be initially disabled. This requires adjusting the knobs
accordingly to enable the missing feature and build a new binary package from
the package source for re-deploying.
Suppose there is no newer version of `sqlite3` in the ports collection. Given
that the version number is essentially fixed in this scenario, how can puppet
be told to re-install (refresh) the same version of a binary package when it is
already installed?
A complex example to this is when a static library is re-compiled for a feature
set change and that library is statically linked into other binary packages,
which they too need to be re-built and re-installed and none of the packages
have a newer version release including the library itself.
Using FreeBSD and SQlite3 as an example, pseudocode for the refreshable feature
for package resource:
<pre>
file {
# This is a FreeBSD port options database file which contains the knobs for
compiling the package source.
# This could also be conceptually similar to, say, a Solaris adminfile, or a
Debian responsefile.
'/var/db/ports/sqlite3/options':
ensure => file,
source => [
'puppet:///modules/...',
],
# Other essential resource properties omitted for brevity.
;
} ~> package {
# If the binary package is not already present, then install it.
# If the binary package is present and has an older version then upgrade it.
# If the binary package is present and is the same version and the contents
of the file has changed then refresh (re-install) it.
# Otherwise, no change to the binary package is needed.
'databases/sqlite3':
version => '3.7.14.1',
# Other essential resource properties omitted for brevity.
;
}
</pre>
----------------------------------------
Feature #17438: Refresh support for package type
https://projects.puppetlabs.com/issues/17438#change-80605
Author: C L
Status: Needs More Information
Priority: Normal
Assignee: eric sorenson
Category: package
Target version:
Affected Puppet version:
Keywords: package refresh refreshable "static library linking" reinstall
Branch:
A number of open-source software can be re-compiled to enable additional
features, or conversely, disable features (e.g.: sqlite3, subversion, etc).
Also some software relies on static linking of other 3rd party libraries (e.g.:
apache, postgresql, etc) which requires a recompile when updates to these
libraries are available.
To deploy changes or re-compiles of such software requires atleast two puppet
runs - the first run to remove the software and the second run to install the
package again. Often this is not convenient, especially when there are
dependencies on the package resource. Likewise, changing the version number of
the software just to force a software update is problematic as it has the
potential to interfere/conflict with the version numbering of the software
distribution itself.
Packages should support the refreshable feature where, in response to a refresh
event, proceed to de-install and then install the software. With refreshable
packages, a file (or in the case of some providers, a response file) could be
used to notify a package to reinstall.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
