Question about location of non-cfg resources.

[mattatobin]

Question about location of non-cfg resources.

[jmanc3]

@mattatobin At the moment, the only place winbar checks for its resources is $HOME/.config/winbar.
It wouldn't be too hard to change it so that it checks /etc/winbar/* instead, and have the install script unzip into that folder.
Of course, since we can't write into that directory we'll still have to save and read transient files from ~/.config/winbar.
Would that work for you?

[mattatobin]

What about a wrapper script which can simply check if the directory exists or not in the user's directory and if not simply unzips and otherwise then runs the actual binary. So point autostart to the wrapper moving the step from "install" to "first run" for any user automagically!

Additionally, you could include a version file in there so the wrapper could be expanded to update resources if desired at some point.

Anyway, I'll do that for my spec file and let you know (and see) how it goes at any rate.

[jmanc3]

@mattatobin Although I didn't write this install script, this is an install script for winbar on the AUR
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=winbar-git

I'm not familiar with rpmbuild but I would guess it's possible for it to do something similar as that script does, which does the unzip as a post step or something.

(On the wrapper script: how would it know where winbar.zip is?)

[mattatobin]

Well, the AUR package extracts the resources to a system share location and then as a post-install step copies it to the user profile. Basically it is a direct translation of the install script more or less.

I don't think RPM has a post-install task that can target a specific user or current user because the only user that can install packages is root when using dnf.

Also, how will the wrapper know where things are? There are a couple ways to deal with that. If it is spec file specific as in not apart of your project then I simply can generate the wrapper with populated locations. If it is part of your setup, then cmake can preprocess it and fill it with paths or some other means like reasonable guess based on the Filesystem Heirarchy Standard.

---

Aside: Openbox, Nemo (with Desktop), and winbar. The recent changes have made it so much better. Endless potential in my opinion.

[jmanc3]

@mattatobin Can rpmbuild unzip winbar.zip into /etc/winbar? That seems like the simplest solution if it can. It's what we should be doing anyways as many of the resources in .config/winbar are not user specific anyways.

[mattatobin]

If you want to follow the FHS, only the initial configuration file should live in etc the resources should live in usr/share/winbar and the program should be handling copying read-only global configuration to the user's config. The build system should also be setup to obey --prefix when configuring and DESTDIR= for installing.

BUUUT that sure is a lot of requirements and the list of demands to be putting upon you all at once. So my solution is the startup wrapper that can serve if/until you decide to perform build system voodoo (and yes it is absolutely voodoo, I know from experience).

To answer your question, yeah, rpmbuild can do anything any script can (though, you may have to disable or override a few rpmbuild assumptions occasionally).