Thanks for the link to the package list. Seems reasonable, I looked around for the i3 config file you indend to ship but coudn't find it. The RPM/Fedora packaging files are unfamiliar to me. (I am sort of self-taught on how to roll Debian packages but am by no means an expert.) Do you intend to ship an i3 config file other than what's provided by the upstream project? If not, then I am guessing it's expected that the new user experience involves directly editing the i3 config file?
In Fedora we use an "Upstream first" approach [1]. So yes, we ship the default i3 config file.
The i3 config file partial implementation is just a shell script that combines files from specific directories into a single file and passes it to i3 upon launch. There are no changes required to i3. Doing this opens the door for a number of use cases but the primary one we need this for now is to decouple the i3 config file from the package specification. For example, you use `feh` to provide the background. If `feh` is referenced in your i3 config file then you would not permit users to uninstall the program as it would break thier system. With a modular, "conf.d" style i3 layout, a meta package that depends on both feh and it's associated i3 config partial could be cleanly added removed as needed by users.
This sounds interesting. If I understand correctly, you should run the script that serves the config file to i3 each time a modification is done, like restarting httpd every time you modify a config file, am I right?
I hope to hear more from you. Thanks for contacting us.