assigned to @evilham
@ander Can you compare those two types, since you have wroten download over the staged file type?
at first I started to write __unpack and then __download just happened, because I didn't like the interface and solution of __staged_file.
and in long run I wanted __download to be bit…
I've had a look at both types. The differences I could see:
nice table 🙏
redownloads file from the source every time.
if you want to deploy same file to multiple hosts, then you should fly with $__files and __file. download caching and parallel…
I'm continuing the discussion of !899 here, because it doesn't really fit there.
I don't know POSIX ACLs well, but I'm wondering if all previous use cases of the deprecated parameters could be…
currently backwards compatibility does exactly that - maps deprecated parameters to --entry and also emits warning.
I think we have waited long enough.
I'll deal with this after dance around…
This question came up when I suggested "cdist-museum" for old and deleted types in cdist core. @poljakowski raised the question if this should also apply to the deprecated parameters in…
sigh, time flies. sorry for taking this long, I have no excuse but laziness 👹
but take a look at !933
I think it was done probably because it's nicer to write __timezone Europe/Tallinn vs __timezone --timezone Europe/Tallinn.
maybe allow object_id if singleton? @poljakowski
Hm...didn't think about the object id. Singleton change which requires parameter would break existing configurations. We should probably go with deprecation and eventually change it to something like…
You are right, it should have been a singleton. I'm not sure what's the best path here for change, as we would need a second type if we want to give users the opportunity to modify their code without…
Maybe we should queue the change for an upcoming 7.0.0 release? IMO breaking API changes are okay for major releases.