[aur-general] Request for Public Review of REXPaint package

Kevin Morris kevr at 0cost.org
Sat Jul 31 21:23:20 UTC 2021


...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:
> > 
> > 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
> 
> 
> 
> -- 
> Kevin Morris
> Software Developer
> 
> Identities:
>  - kevr @ Libera



-- 
Kevin Morris
Software Developer

Identities:
 - kevr @ Libera
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20210731/429cfc64/attachment.sig>


More information about the aur-general mailing list