Hi everyone! Thank you for the help on the the thread eariler, I found the advice and examples very useful. I have posted a request for review of my PKGBUILD over IRC, but I would appreciate any criticism here too.
I have uploaded the PKGBUILD, and two files that would come with it (launcher.desktop and launcher.sh). There are a couple decisions I made that are unconventional, so I'll list them here:
1. As George suggested, I renamed my package from `rexpaint-bin` to just `rexpaint`, since there are no sources available.
2. The server hosting the program blocks Curl's user agent. As far as I can tell, the convention is to use "Mozilla" as a user agent instead. However, I have opted to use "PKGBUILD" as the agent, so I avoid accidentally messing up any statistics that may be collected upstream.
3. I have used standard package permissions as far as I can tell, except for `/usr/share/rexpaint/images`. The program saves data into this directory, so it must be 777.
4. I am not sure what to do with `/usr/share/rexpaint/data`. It contains data such as fonts and palettes, which might be edited by the user during usage. Right now I have assumed that the user will not do that, so it is not listed in `$backup` and its mode is 755. I have sent an email upstream asking about this, and am waiting for a response.
5. The program tries to write logs into the Working Directory (`/usr/share/rexpaint`), but it cannot do this because I have set its mode to 755. However, giving the everyone write permissions in `/usr/share/rexpaint` seems insecure. Please advise.
As stated before, I have emailed upstream to ask if it's okay that I publish this packaging to the repositories. This is not required by the license, but I am too young to be making enemies, and it would be nice to have some upstream. I will publish it when I get the goahead, or if he takes more than 24h to reply.
All feedback is appreciated.
Thank you in advance, Vincent
That is absolutely insecure. Upstream should probably provide a way to provide overrides to those files, which probably means also dealing with prioritizing an override location over /usr/share defaults.
Some packages have used /opt to do things like this in the past. Personally, I try to avoid using /opt with system packages, because it differentiates how things are organized for packages in the root filesystem.
Some options would be things like: $HOME/.config/<package>/... or some XDG directory for overrides.
Regards, Kevin
On Sat, Jul 31, 2021 at 01:26:00PM +0000, Vince via aur-general wrote:
Hi everyone! Thank you for the help on the the thread eariler, I found the advice and examples very useful. I have posted a request for review of my PKGBUILD over IRC, but I would appreciate any criticism here too.
I have uploaded the PKGBUILD, and two files that would come with it (launcher.desktop and launcher.sh). There are a couple decisions I made that are unconventional, so I'll list them here:
As George suggested, I renamed my package from `rexpaint-bin` to just `rexpaint`, since there are no sources available.
The server hosting the program blocks Curl's user agent. As far as I can tell, the convention is to use "Mozilla" as a user agent instead. However, I have opted to use "PKGBUILD" as the agent, so I avoid accidentally messing up any statistics that may be collected upstream.
I have used standard package permissions as far as I can tell, except for `/usr/share/rexpaint/images`. The program saves data into this directory, so it must be 777.
I am not sure what to do with `/usr/share/rexpaint/data`. It contains data such as fonts and palettes, which might be edited by the user during usage. Right now I have assumed that the user will not do that, so it is not listed in `$backup` and its mode is 755. I have sent an email upstream asking about this, and am waiting for a response.
The program tries to write logs into the Working Directory (`/usr/share/rexpaint`), but it cannot do this because I have set its mode to 755. However, giving the everyone write permissions in `/usr/share/rexpaint` seems insecure. Please advise.
As stated before, I have emailed upstream to ask if it's okay that I publish this packaging to the repositories. This is not required by the license, but I am too young to be making enemies, and it would be nice to have some upstream. I will publish it when I get the goahead, or if he takes more than 24h to reply.
All feedback is appreciated.
Thank you in advance, Vincent
...Apologies, I should have thought about this during the first reply, but, you could always use things like XDG_RUNTIME_DIR to store this "data" for a user running the program, then they'd get their own little filesystem directory of user-modifiable things.
Since this seems to be possibly automated in some ways, that's probably a better idea than using $HOME/.config for something like this.
Regards, Kevin
On Sat, Jul 31, 2021 at 02:20:48PM -0700, Kevin Morris via aur-general wrote:
That is absolutely insecure. Upstream should probably provide a way to provide overrides to those files, which probably means also dealing with prioritizing an override location over /usr/share defaults.
Some packages have used /opt to do things like this in the past. Personally, I try to avoid using /opt with system packages, because it differentiates how things are organized for packages in the root filesystem.
Some options would be things like: $HOME/.config/<package>/... or some XDG directory for overrides.
Regards, Kevin
On Sat, Jul 31, 2021 at 01:26:00PM +0000, Vince via aur-general wrote:
Hi everyone! Thank you for the help on the the thread eariler, I found the advice and examples very useful. I have posted a request for review of my PKGBUILD over IRC, but I would appreciate any criticism here too.
I have uploaded the PKGBUILD, and two files that would come with it (launcher.desktop and launcher.sh). There are a couple decisions I made that are unconventional, so I'll list them here:
As George suggested, I renamed my package from `rexpaint-bin` to just `rexpaint`, since there are no sources available.
The server hosting the program blocks Curl's user agent. As far as I can tell, the convention is to use "Mozilla" as a user agent instead. However, I have opted to use "PKGBUILD" as the agent, so I avoid accidentally messing up any statistics that may be collected upstream.
I have used standard package permissions as far as I can tell, except for `/usr/share/rexpaint/images`. The program saves data into this directory, so it must be 777.
I am not sure what to do with `/usr/share/rexpaint/data`. It contains data such as fonts and palettes, which might be edited by the user during usage. Right now I have assumed that the user will not do that, so it is not listed in `$backup` and its mode is 755. I have sent an email upstream asking about this, and am waiting for a response.
The program tries to write logs into the Working Directory (`/usr/share/rexpaint`), but it cannot do this because I have set its mode to 755. However, giving the everyone write permissions in `/usr/share/rexpaint` seems insecure. Please advise.
As stated before, I have emailed upstream to ask if it's okay that I publish this packaging to the repositories. This is not required by the license, but I am too young to be making enemies, and it would be nice to have some upstream. I will publish it when I get the goahead, or if he takes more than 24h to reply.
All feedback is appreciated.
Thank you in advance, Vincent
-- Kevin Morris Software Developer
Identities:
- kevr @ Libera
Hi Kevin, Thank you for replying with useful feedback. I will try to find a way to make logging more secure. Using $XDG_RUNTIME_DIR is probably the solution I will go with (If I find a way to override the log location).
Considering what you have said, I should probably find a better place to store saved images. I will read through the XDG specs to find something. $XDG_DATA_HOME/rexpaint or $XDG_DATA_HOME/rexpaint/images could both be options, but I'll think further tomorrow. If I'm talking nonsense, please let me know. Once again, this is provided I find an elegant way to pull such a thing off.
Once again, thank you for the feedback. It seems that packaging REXPaint won't be quite as simple as I expected;)
Thanks again, Vincent
aur-general@lists.archlinux.org