Packaging + user configuration

[zarigzu]

I was wondering if we could write some installation targets on the Makefile that would install the source files so that we can make packages that distributions can use and users can configure more easily.

What I mean is that regular (binary) packages of dwm are a bit pointless because they are not configurable since you'd have to actually have the source code, edit it, rebuild and repackage. So instead we could install the main source files in /usr/src/dwm, and provide a target that recompiles dwm reading only from the configuration files patches.h, config.h and config.mk that could go in ~/.config/dwm.

For users, the goal is that they can install/uninstall dwm-flexipatch with their package manager; manage their config files like other programs in ~/.config; rebuild with make -C /usr/src/dwm rebuild and still have the benefits of running a small efficient executable

For package maintainers this would mean they can just use the new targets like make all-src && make install-src for these "source-packages" and not implement this logic in a packaging script

The main issue with this approach is what to do with the actual dwm executable (and possibly dwm-msg). If the rebuild target installs in /usr/bin/dwm, users would have to run make with elevated privileges and maybe package managers complain that a file was modified.

A solution can be that when /usr/bin/dwm executes, it execs another program in a user-owned directory if available, like ~/.local/lib/dwm/dwm, so users can rebuild there without sudo and each user have their own build. This could be achieved with a wrapper script or with a patch.

I have a rough prototype of this but I was wondering if it would belong here.

[bakkeby]

It is an interesting topic, even if it would be a once-in-a-lifetime scenario where there are multiple users sharing the same computer and all running their own version of dwm.

I think your ideas are on the right track.

The way I imagine this would work is that given that the binaries are essentially hardcoded they will need to be installed on a per user basis. This means that the dwm binaries will need to be installed under ~/.local/bin/ as you have suggested.

That is achieved by changing the PREFIX setting in config.mk and this allows for dwm to be compiled without the use of sudo. The Makefile also refers to an unused DESTDIR variable that could be taken advantage of as well.

The base source files could be shared as suggested under /usr/src/dwm/, installed by the package manager.

There will be a dwm.desktop file that would have to be copied to either /usr/share/xsessions/ or /usr/local/share/xsessions/. I don't think that you can use ~/.local/ here.

That dwm.desktop file would run a script like this: Exec=/usr/local/bin/startdwm.sh

And the startdwm.sh script I would imagine would check and exec ~/.local/bin/dwm if it exists, and if not then it would do the initial setup like copying the required files (patches.h, config.h, config.mk and Makefile) to e.g. ~/.local/src/dwm/ (?) and likely do some sed replacements to make it look for other source files under /usr/src/dwm/, to start the compilation, and finally exec the compiled binary if it was successful.

Perhaps convoluted but I think that it should be possible to get something like this to work.

Not sure how much of this would fit into this project, but I suppose that it might be possible to have a separate repository that would handle this, possibly using dwm-flexipatch as a submodule or have a Makefile that does a shallow clone or something like that.

Just my ideas on the topic.

[zarigzu]

Thanks for your feedback, I was indeed using dwm-flexipatch as a submodule but I thought it might be better to discuss it here since this repo is already an easier entry-point for users that want to try dwm, we could make it even easier with packaging and user configuration.

This is one possible way to implement what I was talking about:
bbd19fc

We create new targets, crucially the ones I called all-src, install-src and rebuild.

• all-src is like all but would compile dwm by reading the config files ${CONFIGDIR}/config.h and ${CONFIGDIR}/patches.h.
• install-src is like install but would also install the source files in ${DESTDIR}${PREFIX}/src/dwm (usually /usr/src/dwm).
• rebuild is a target a user can run that would compile a local dwm in ~/.local/lib/dwm (this could be changed to ~/.local/bin) and also read from the config dir.

The ${DESTDIR}${PREFIX}/bin/dwm (usually /usr/bin/dwm) that the user with a source-installation would get just execs ~/.local/lib/dwm/dwm if available or fallback to /usr/lib/dwm/dwm if available (maybe for a distribution package maintainer to provide their default dwm version)

A packing script can now use the first 2 targets, for example for Arch Linux
https://github.com/zarigzu/dwm-flexipatch/blob/packaging/packaging/PKGBUILD

After installing, a user can rebuild their own with make -C /usr/src/dwm rebuild and
doesn't need to repackage. Their ~/.config/dwm/* will be used when rebuilding.

The reason I don't just use PREFIX and DESTDIR to install like make PREFIX=$HOME/.local for example, is because some package managers would install with root permissions like pacman for Arch (btw I think they might have discussed this a few years ago but I don't know what happened). Having this logic as a make target can be easier for package maintainers.

I made the dwm.sh script be installed as just dwm so the .desktop file doesn't have to be modified. I think it's also possible to achieve this with a patch, a perhaps cleaner solution can be that /usr/bin/dwm is a binary that runs the default version the distribution wants to provide (the one I called /usr/lib/dwm/dwm), unless it finds a ~/.local/lib/dwm/dwm, then it would run that one. Users can then decide if they want this behavior with a macro (e.g. #define DWM_LOCAL_PATCH 1) and configuration in their ~/.config/dwm/config.h

This is just a rough version, we could polish it

[bakkeby]

I'll need more time to go through this in more detail, but I was thinking that you wouldn't actually need to do any compliation from a package manager perspective if all you are doing is getting the source files + custom scripts and package maintainer's custom (default) config.

My line of thinking was that the startup shell script would do the initial user installation automatically the first time the user tries to "log in". I was also thinking that the user would rebuild their own dwm by running a command like make -C ~/.local/src/dwm rebuild provided that the directory would also contain a bespoke Makefile.

I think that it may be conceptually simpler if there is just a user binary and no bespoke global dwm binary.

[zarigzu]

I was thinking that you wouldn't actually need to do any compliation from a package manager perspective if all you are doing is getting the source files + custom scripts and package maintainer's custom (default) config.

Yes, we could just install the source files and have the installed Makefile read from the ~/.config. If a package maintainer wants to provide a custom default config or binary they can write that logic themselves in the packaging script. I was just thinking of providing a target might be easier for them (or any user that'd want this setup and doesn't have a package manager). I agree it'd be conceptually simpler.

I haven't seen packages providing source code meant to be compiled, so I just threw this "default binary for maintainers" idea in the code but I don't mind scrapping it.

My line of thinking was that the startup shell script would do the initial user installation automatically the first time the user tries to "log in"

That sounds good. It could check if a local dwm doesn't exist and if so, compile it first, then exec it

I was also thinking that the user would rebuild their own dwm by running a command like make -C ~/.local/src/dwm rebuild provided that the directory would also contain a bespoke Makefile.

I don't know if the Makefile/source code should go in ~/.local/src, because as I said the package manager may install it with root permissions and not meant to be changed, so ~/.local doesn't seem appropriate. It would be fine for a user that doesn't use a package manager, they could just do make PREFIX="$HOME/.local", but for package maintainers they'd want to use make PREFIX=/usr.

I get that this would be tricky for the Makefile, since now it has to include config.mk from ~/.config/dwm, but I already wrote how a sed replacement would go.

If you want I'll write an easier commit with these changes

[rharmonson]

On packaging dwm-flexipatch. Reading this as a unofficial debian package maintainer. A couple thoughts come to mind. What are the target distributions? Most distros provide source packages which permit customization, build, then install. It is not a feature often touched on. Perhaps due to it requires more than a causual understanding of the package manager. Advantage of using a distro's package is build and installation dependencies are baked-in and in debian you can flag other conflicting packages to prevent their installation which permits the use of default installation locations.

An installation script may be simpler.

On debian for system-wide installed software that requires compiling is typically installed in /usr/local/ with user equivalent as ~/.local/ as stated above. This is true for app.desktop files as well, ~/.local/share/applications/. The primary challenge is updating the users environment to support ~/.local/bin and so forth for many distros do not map by default. Could be part of the README.md file. It is a neat idea and I have seen other projects create installatin shell scripts where the user copies and pastes a one-liner and voila, the software is installed.

Obviously, build dependencies would need to be installed.

Happy to contribute by spinning up a debian virtual machine and other distros to test. Sounds like fun.

[zarigzu]

Hi @rharmonson, I can at least contribute to Arch Linux's AUR with dwm-flexipatch and dwm-flexipatch-git packages. One for a fixed version and the other for the latest git commit.

Most distros provide source packages which permit customization, build, then install.

What exactly do you mean by this? I think you mean that the source code is downloaded for building, then the package maintainer (or non-casual user) can add customization like reading a local config.h, rebuild and repackage, right? I'm aware this exists, as in the AUR there's a dwm-git package that does it, providing the following files:

/usr/bin/dwm
/usr/share/xsessions/dwm.desktop
/usr/share/man/man1/dwm.1.gz
/usr/share/licenses/dwm/LICENSE
/usr/share/doc/dwm/README

The user can then edit their local config.h that is in a building directory and rebuild-repackage-reinstall (in Arch Linux: makepkg -si)

My idea is not that but to actually install the source code with the package manager so users can avoid the repackage-reinstall steps. It would provide these files:

/usr/bin/dwm    ← a wrapper executable that execs the actual one
/usr/src/dwm/dwm.c
/usr/src/dwm/Makefile
/usr/src/dwm/drw.c
/usr/src/dwm/patches.def.h
/usr/src/dwm/config.def.h
/usr/src/dwm/transient.c
/usr/src/dwm/util.c
/usr/src/dwm/util.h
/usr/src/dwm/patch/**
/usr/share/xsessions/dwm.desktop
/usr/share/man/man1/dwm.1.gz
/usr/share/licenses/dwm/LICENSE

but the Makefile would read config.h, config.mk and patches.h from ~/.config/dwm and output the actual executable to ~/.local (still unsure if on lib or bin). A package made with this structure can still set its dependencies, conflicts, etc. as in my example

On debian for system-wide installed software that requires compiling is typically installed in /usr/local/

This is for user-manually-compiled software, like where dwm-flexipatch installs by default (PREFIX = /usr/local in config.mk). Software provided by package managers usually use PREFIX=/usr instead. The issue is that these system-wide directories /usr and /usr/local are owned by root so you also install as root (sudo make, sudo apt) or in another directory like make PREFIX="$HOME/.local" install

Since I proposed user configuration in ~/.config, it'd make sense that users don't have to elevate privileges after installing by building a local executable. The setup I proposed prepares this environment and compiles there (mkdir -p ${LIBDIR}, ${CC} -I ${CONFIGDIR} -o ${LIBDIR}/dwm ${OBJSRC} ${LDFLAGS})

Happy to contribute by spinning up a debian virtual machine and other distros to test. Sounds like fun.

Thanks, it'd help. As I said, the package would provide those files. What distros are you familiar with their packaging?

After figuring out a good setup, I'm also thinking automating releases with Github Actions to provide fix-version archives (.zip or .tar.gz) with that structure that package maintainers can use. Maybe even automate releasing the most common package formats .deb, .rpm here. I haven't used .github/workflows yet but I know this is possible.

[rharmonson]

What exactly do you mean by this? I think you mean that the source code is downloaded for building, then the package maintainer (or non-casual user) can add customization like reading a local config.h, rebuild and repackage, right?

Exactly what I meant.

My idea is not that but to actually install the source code with the package manager so users can avoid the repackage-reinstall steps.

Understood and I did something similiar on my older antiX dwm-flexipatch spin. I moved to 100% debian packaging for dusk since it permitted easier maintenance but both are equally good approaches based on what is the goal.

Since I proposed user configuration in ~/.config, it'd make sense that users don't have to elevate privileges after installing by building a local executable.

Good point. Deiban package policy doesn't permit the use of user dirctories whatsoever in packages. Of course, one doesn't have to stick to the policy if you do not submit them for inclusion in the official repository.

What distros are you familiar with their packaging?

Debian packaging is the only one I feel moderately competent. I used to build and maintain rpms but I have stepped away from red hat and its derivatives after twenty-five years.

[rharmonson]

After figuring out a good setup, I'm also thinking automating releases with Github Actions to provide fix-version archives

Meant to add that using Github Actions would be awesome. Not done it myself but I have seen projects do it for more popular distirubtions. It is a neat idea, but beyond my skillset.