-
-
Notifications
You must be signed in to change notification settings - Fork 41
101.3 Styling
101.1 Variables | 101.2 Functions | 101.3 Styling | 101.4 Submitting a Pacscript | 101.5 Maintaining a Package
You need to save your script file as ${pkgname}.pacscript
. To add a package to pacstall-programs
, fork the repository, and create a directory packages/${pkgname}
; then, add ${pkgname}.pacscript
inside it. You also must edit the file at the head of the repository called packagelist, and add your new ${pkgname}
to the list. Finally, create a pull request.
Example of script placement:
.
├── packagelist
└── packages
└── foo-bin
└── foo-bin.pacscript
You can test your package by cd'ing into the directory containing ${pkgname}.pacscript
and running pacstall -I ${pkgname}.pacscript
. If it works, good! If not, Pacstall should tell you what went wrong.
A few internal functions may be used, but are advised against unless absolutely necessary:
-
The function ask will get user input for Y or N.
-
The function fancy_message will print text inline with pacstall's formatted output.
-
The functions
parse_source_entry
andcalc_git_pkgver
, in conjunction with each other, will calculate a commit hash from a source, and return it tocomp_git_pkgver
. Example:
parse_source_entry "${source[4]}"
calc_git_pkgver && echo "${comp_git_pkgver}"
Pay attention to how symlinks are installed in {prepare,build,check,package}
. If we had a pacscript that looked like this:
package() {
ln -s "${pkgdir}/usr/bin/neofetch" "/usr/bin/brokenlink"
}
$ file /usr/bin/brokenlink
/usr/bin/brokenlink: broken symbolic link to /usr/src/pacstall/neofetch/usr/bin/neofetch
The reason this happens is because ${pkgdir}
is a staging area that will eventually be removed after the deb is created. You can think of ${pkgdir}
as a temporary /
for package files.
How we handle it is to pre-suppose the destinations of the symlinks, like so:
package() {
mkdir -p "${pkgdir}/usr/bin"
ln -sf "/usr/bin/neofetch" "${pkgdir}/usr/bin/fixedlink"
}
In this example:
- Our file is currently at
${pkgdir}/usr/bin/neofetch
, but will end up at/usr/bin/neofetch
, so we make the link to the end destination. We add-f
for this declaration. - Additionally, because we want our symlink to be contained within the package, we create it inside of
${pkgdir}
. - This means created symlinks cannot be run inside of
{prepare,build,check,package}
, only once installed.
Rarely will you ever need or want to touch the users home directory, and we encourage you to not touch it, however if you need to (and only as a last ditch attempt), you can handle files (such as configs, but never application data) like so:
package() {
cp -r .config/* /etc/skel/.config/
}
post_install() {
# Note the absence of sudo
# Use ${homedir} instead of trying to get the users home directory
# by trying `/home/$USER` or things in that nature
cp -r "/etc/skel/.config/foobar" "${homedir}/.config"
}
If a package will create a configuration file in the home directory on first run, do not manually create one in the pacscript. If you must modify the user's home directory in post_install
, post_upgrade
, or post_remove
, use the $homedir
variable provided by pacstall as a substitute for $HOME
or ~
.
You must not use features that are not in the master branch (latest release of Pacstall).
Pacscripts should ideally be feature complete with their respective PKGBUILDs if available.
Look at other Pacscripts for reference.
For tips on best practices with build tools like meson
or cargo
, see here.
Lastly, do not ask the user for any input unless absolutely necessary, because we will not accept scripts otherwise. Use external variables to detect what you need to know before asking the user.
As for styling, please use 2 spaces as a tab. You should format all scripts with shfmt -bn -ci -sr -s -i 2 -w $pkgname.pacscript
.