Systemd service layout option improvement

[SelfRef]

While packaging this driver for Arch Linux (1, 2), I've noticed the .service unit is meant to be altered by install.sh with the correct layout. The problem is Arch packages shouldn't be interactive and package service should be installed in /usr/lib/system/system which in design is considered immutable.

To resolve that problem, I suggest one of two solutions:

1. Ideally, the LAYOUT parameter should be read by the main script from config file under /etc/asus-stylus
2. Systemd supports instantiated units that can contain parameter further read inside as %i
   So the unit after adding @ to the name and started as e.g. asus_stylus@SA201H.service could look like this:

// asus_stylus@.service
ExecStart=/usr/bin/env python3 /usr/share/asus_stylus-driver/asus_stylus.py %i

[ldrahnik]

@SelfRef Hi, thank you for packaging the driver for arch. Could you pin here any concrete example(s) how deal with config files other arch packages? What Is considered as the best practise?

[SelfRef]

Hi @ldrahnik and sorry for the delay.

Theory

All general practices are well explained in guideline. On the bottom of this page there is a section with language-specific packages like Python where often information about the correct files location and other requirements can be found like the build process.

But generally Arch is using canonical hierarchy standard (original, Wikipedia) so if an application is correctly structured for general Linux, it does not require any additional changes to be packaged for Arch. There are some minor changes that are worth of taking into account like /bin, /sbin, /lib, /lib64 being linked to /usr/(...).

The most important in most cases is that /usr can be read-only, so anything that package is installing under there have to be immutable. The default configuration should be in /usr/share/<pkg>, the application variable files in /var/lib/<pkg> and configuration mean for user to edit in /etc/<pkg> (hence my 1. solution suggestion).

There are separate requirements to handle systemd units. Aside from official documentation, there is a page on the ArchWiki for that ones. The most important is the location of installed unit files which for packages is /usr/lib/systemd/system/ thus this file cannot be mutable by the user by design.

When I'm not sure how a software should be packaged, I try to look at similar software in AUR and peek into it's PKGBUILD file.

Practice

Summarizing how this project could be structured, in my opinion:

1. Implementing standard PEP 517 will ensure the software is distro-agnostic and can be easily packaged into any type of package
   • if I'm not mistaken, it will install files to /usr/lib/python<ver>/site-packages/<pkg>
   • and by that custom install.sh will not be necessary
   • ArchWiki even have specific instructions for these packages
   • this is a step I'm not experienced with, so I won't be able to assist much
2. Systemd unit file should not contain any variables meant to be modified by user; just instructions how to run the service and service by itself should care about configuration
   • also, the correct path is /usr/lib/systemd/system/
3. Config file(s) (can be anything, INI, YAML, JSON) should be placed in /etc/<pkg>/file.ext
   • Python script is responsible for loading it; for convenience it can look for many locations like /usr/share/..., then /etc/...
   • default configuration can be provided under /usr/share/<pkg>/, in this case there may be no /etc/<pkg>/ file until user will create it himself, basically overriding default configuration
4. Executable file (and only that one) have to be installed in /usr/bin
   • it can be the main Python file, but even better - it should be a script to run the main Python file

In case of any questions don't hesitate to ask, I will help as much as I can :)

[ldrahnik]

@SelfRef Thank you for exhausting summary. Don't you want to contribute to this project? Try to implement the mentioned ideas in PR?

[SelfRef]

Sure. I can make these changes. Soon I'll have some spare time so I'll do improvements and share PR 😉