Add
* update by patching
and make the policies platform and machine specific.
Then call the implementation something catchier than ansible or DevOps.
Seriously: configuration != package management.
--
You are receiving this because you commented.
Reply to this email directly or view it on
Just to enumerate what sort of things an update policy would consist of, from
the top of my head:
- whether to install the file in the first place (default obviously yes, but
%ghost does not get installed at all)
- whether to replace files (default being yes, currently only changable with
Thinking about it some more... what we're actually talking about here is a file
update policy. An update policy is a selection of operations such as whether to
replace modied files or not, to backup or not etc. When looking at it from this
perspective, it all starts making more sense: %config
I try to sum up what I think that should be done with this issue.
Name is unresolved. I chose "mutable" as an interim one.
%mutable will be defined for REG files and LINKs.
Behavior :
- if a file/link is the same as in new package
(it has the same contents, gid, uid and
Hmm...
Also makes me wonder if such a file should be updated IFF the on-disk file
hasn't been altered since installation - consider a case where the initial
content is somehow incorrect and a later package version corrects this.
Another possible name for the thing, especially if it IS updated
Just yesterday, I had usecase for this.
I am packaging updated Vagrant and there is used "plugin.json" file. We used to
store it in ```%{_datadir}/vagrant/plugin.json``` and it used to be ghost file.
But upstream changed some internals and now it is not possible to convince
Vagrant to use the
