__acl: remove deprecated parameters #43

Closed
opened 2021-11-20 11:25:07 +00:00 by ungleich-gitea · 9 comments

@ander Can you remove __acl deprecated parameters and prepare MR?
In the ++minor we will remove them.

@ander Can you remove `__acl` deprecated parameters and prepare MR? In the ++minor we will remove them.
ander was assigned by ungleich-gitea 2021-11-20 11:25:07 +00:00
Author
Owner

mentioned in commit f96f23e970

mentioned in commit f96f23e970abd586fe222b296f1f010e52c364e5
Author
Owner

closed via merge request !933

closed via merge request !933
Author
Owner

mentioned in merge request !933

mentioned in merge request !933
Author
Owner

sigh, time flies. sorry for taking this long, I have no excuse but laziness 👹

but take a look at !933

sigh, time flies. sorry for taking this long, I have no excuse but laziness :japanese_ogre: but take a look at !933
Author
Owner

@ander Is it feasible that you do this in a week or two?

@ander Is it feasible that you do this in a week or two?
Author
Owner

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 __acl.

IMO: If no use case breaks and it's just a matter of switching from one parameter to another, there is no reason to archive the old version.

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 `__acl`. IMO: If no use case breaks and it's just a matter of switching from one parameter to another, there is no reason to archive the old version.
Author
Owner

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 __download and __unpack ends in one way or another.

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 `__download` and `__unpack` ends in one way or another.
Author
Owner

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 mapped to a new --entry parameter?
If not, which cases do not work anymore if the deprecated parameters are removed?

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 mapped to a new `--entry` parameter? If not, which cases do not work anymore if the deprecated parameters are removed?
Author
Owner

mentioned in merge request !899

mentioned in merge request !899
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#43
No description provided.