Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Add copy target type #77

Open
dixslyf opened this issue Jul 17, 2021 · 4 comments
Open

[FEATURE] Add copy target type #77

dixslyf opened this issue Jul 17, 2021 · 4 comments

Comments

@dixslyf
Copy link

dixslyf commented Jul 17, 2021

Is your feature request related to a problem? Please describe.
I am configuring a theme for SDDM (an X display manager) that requires an image file to be placed somewhere in /usr/share/sddm/themes/, so privilege escalation is required.

My dotfiles folder is located in my home directory, so it is not ideal to use a symlink because firstly, it is a security risk; and secondly, it doesn't really make sense for a system-wide configuration file to symlink to a user file.

Furthermore, my home directory is encrypted using fscrypt, and is only unlocked after logging in, so using a symlink wouldnt't work.

Using the template target type allows us to copy text files, but for non-text files, we get stream did not contain valid UTF-8 as the file stream is interpreted as UTF-8.

Describe the solution you'd like
A new copy target type that can be specified when configuring a complex target:

[some_package.files]
'some_image.png' = { target = '/some/system/directory/some_image.png', type = 'copy', owner = 'root' }

I think this would be useful in conjunction with the owner field and for other scenarios in which symlinks aren't desirable.

Describe alternatives you've considered
I've tried:

  • using the template target type, but as mentioned above, this won't work for non-text files
  • using the post-deploy hook to manually copy the file, which works, but it's not really an elegant solution
  • creating a separate dotfiles folder in the root directory and then running dotter as root, which also works, but ideally I would like to have all my dotfiles in one location

Additional context

$ uname -srvo
Linux 5.10.42-1-MANJARO #1 SMP PREEMPT Thu Jun 3 14:37:11 UTC 2021 GNU/Linux
@SuperCuber
Copy link
Owner

SuperCuber commented Jul 17, 2021

This does seem pretty important to support to me. I'm debating whether it should be a new type or if it's enough for the template type to fallback to copying on non-utf files... I'm leaning towards the latter, but I need to check which would make more sense in the context of the code.

PR appreciated :D

@dixslyf
Copy link
Author

dixslyf commented Jul 17, 2021

I think it would make more sense semantically for it to be a new type as it doesn't really make sense to template non-text files (e.g. binaries, media, etc.). Relying on a fallback to copy feels more like a hacky approach, and may not be intuitive to users.

There's also an opportunity for a performance benefit. If I have some non-templated text files that I want to copy somewhere as is, I could specify the target type as copy instead of template so that we don't run all the Handlebars processing unnecessarily.

I'd be happy to write up a PR! Though I'm quite limited on time so no guarantees.

@SuperCuber
Copy link
Owner

Good points and I agree. Also, the error message for non-utf templates could hint you to use copy instead.

@sharpenedblade
Copy link

Until this happens can there be a warning when the target is outside $HOME.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants