[wpkg-users] configuration and change management (ccm) with wpkg: how?

[Holger Kröber]

Hi Dafydd,

Am 20.10.2015 um 11:58 schrieb Dafydd Jones (techneg.it):
> Holger,
>
> looking at your ccm package, the issue is how you differentiate config 
> versions.
> You use an exists check, but the file already exists.
I don´t think that this causes the problem. Reason I: the second time i 
executed the package, the chained package wasn´t even processed (i 
verified this with the /debug parameter)
Reason II: i deleted some of the files that have been copied the first 
time - the second time they didn´t reappear.
> I use a filesize check, because when I change a configuration that 
> often changes the file size, and when it doesn't I add some extra 
> comment. You could also compare the date of a file.
I guess it depends on the situation if a filesize check is preferable to 
"execute=once". Having 5 big files and only one of them changes -> use 
filesize check. Have 3 little txt-files and
one or all changes ->execute=once will do it.
>
> On upgrade, you only increment the config package revision number, not 
> both.
I will try this out.
Thanks,
Holger
>
> HTH,
> Dafydd
>
> On Tuesday, 20 October 2015, Holger Kröber 
> <kroeber at biom.uni-freiburg.de <mailto:kroeber at biom.uni-freiburg.de>> 
> wrote:
>
>     Hi,
>
>     often, after you´ve deployed a package some changes or
>     modifications are required for this package.
>     E.g. you have to (re-)configure the proxy settings for firefox etc.
>     I think that most of you implement change and config managment
>     (ccm) directly inside the package of the application itself.
>     But what happens, if you already deployed the package and then you
>     have to configure some settings for this package later?
>     The way wpkg works, you would have to modify the app package, add
>     some check conditions (e.g. with firefox: check file
>     exists mozilla.cfg etc), increase the revision number
>     and....accept that wpkg will reinstall your complete
>     application/package
>     and not just only makes the desired configuration changes. Maybe
>     it´s ok for you with a small package like firefox - but there also
>     exists big software.
>
>     So i am searching for a way to avoid a reinstallation of a already
>     installed package while deploying new settings for this package.
>     My first thought was to outsource the ccm into a new package
>     (firefox_ccm) and then chain this package to the app package
>     (firefox-esr).
>     This will work if the app package is installed for the first time.
>     If i later update the ccm package (because i have to deploy new
>     settings) and
>     increase the revision number for both packages and then call the
>     app package, the chained ccm package will be ignored.
>     I use precheck-upgrade="always" in my packages - if i remove this
>     line the chained package will not be ignored - but than i will have
>     again the problem that the complete application reinstalls. So i
>     guess that chained packages only work in install-mode, not in
>     upgrade-mode
>     when using precheck-upgrade="always". Maybe i have to use a
>     different approach...
>
>     How you guys manage ccm in your environment? Got some tips for me?
>
>     Thanks,
>     Holger
>
>
>
> -------------------------------------------------------------------------
> SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
> http://www.sslrack.com/
> -------------------------------------------------------------------------
> wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
> _______________________________________________
> wpkg-users mailing list
> wpkg-users at lists.wpkg.org
> https://lists.wpkg.org/mailman/listinfo/wpkg-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20151020/79310370/attachment.html>