Consider using a build system

[dusansimic]

This is a suggestion for overall maintenance of the project. Some icon themes (and many projects in general, regardless of whether they have source code or are just assets) use a build system or installation scripts to ease the installation process of the icon theme. Essentially, only the installation part of the build system would be used.

My recommendation would be meson. It's widely used in GNOME projects (essentially used as a standard build system) and for example Yaru icon theme uses it.

The benefit would be having a universal way of installing the icon theme. An issue was raised on AUR package morewaita-git regarding the packaging process of the icon theme which also affects the morewaita package since they use the same packaging process. The gist of the issue is that a cloned git repo is effectively corrupted (by moving it elsewhere). It won't break the packaging process as stated in the comment because the next step in the script is actually moving the repo directory which would on the next update require another cloning of the repo but it is however a bad practice. The reason I chose this way of installing is so I wouldn't need to manually install all icon directories and track if there were some changes in the project structure.

That whole issue would be avoided if the process of making install scripts (effectively using a build system) would be offloaded to the project itself while package maintainers are responsible for properly executing build system commands for a specific distro. That way the installation process could be changed while there is no need for intervention from package maintainers because the build system handles the installation.

The reason I'm suggesting a build system over simple install scripts is because I found it much easier to maintain, especially if at some point the project starts to scale. A simple install script might by a quick solution but not a long term one in my opinion. Also a build system has a fairly standardized cli which is better than a custom script which a package maintainer would first need to understand before knowing what to do with it (the same is applicable with build system but again, it standardized compared to custom scripts). I could help out with working on adding the build system to the project.

[somepaulo]

Thank you for the detailed explanation. I have nothing against the proposal in general as long as it's not one of those implementations that litter the home folder or pull in dependencies through language specific package managers like pip that the system has no way of knowing about. Build systems are totally unexplored turf for me from a developer's point of view, and I have no time for the learning curve atm, so if you're willing to implement this, I'll merge or give you write access, whichever works best for you.

[realmazharhussain]

I can do it if you like. But the theme related stuff would have to be moved into a subdir for easy integration with meson. It can be done without moving anything but then when you add new types of icons (e.g. mime types were added recently), meson.build file will have to be modified to accommodate that change.

However, if we do move the theme into its own directory, meson.build will probably never need to be changed again except of course when changing version number or renaming the sub-directory.

After moving, the directory structure should look something like

MoreWaita/
├── .github/
├── icons/
│  ├── apps/
│  ├── apps@2x -> apps/
│  ├── mimes/
│  ├── mimes@2x -> mimes/
│  ├── panel/
│  ├── panel@2x -> panel/
│  ├── places/
│  ├── places@2x -> places/
│  ├── status/
│  ├── status@2x -> status/
│  └── index.theme
├── AUTHORS
├── LICENSE
├── meson.build
└── README.md

[realmazharhussain]

Sorry! Upon further investigation, I found out that meson does not support installing a subdir with its symlinks intact. It copies their targets instead. But we want to keep the symlinks intact.

So, there is no need to move stuff and any change in directory structure (e.g. adding a new category of icons) will always require modifying meson.build file.

[dusansimic]

I personally don't mind having to change meson configuration all the time. What we benefit from it is a standardized installation method and the downside would be having to add a few lines to the meson config every time a new icon is added. If it's documented properly, I think anyone could be able to do it. I'll try to write a first draft this weekend if that's fine by everyone.

[somepaulo]

the downside would be having to add a few lines to the meson config every time a new icon is added.

So if I create a new icon and a handful of symlinks to it I'll have to manually add each new filename to the meson config, right? In my workflow I push new icons to GitHub and then update my actual installation through the AUR to test, and I'd like to be able to keep doing that.

[dusansimic]

In my workflow I push new icons to GitHub and then update my actual installation through the AUR to test, and I'd like to be able to keep doing that.

Those steps in your workflow wouldn't change. You will only have to insert filenames and links into the meson specification after adding the icons and before pulling from aur.

Again, that would make no difference to the user but to a package maintainer it would standardize a packaging process.

[somepaulo]

Then I have no objections.
I'm already doing it with my local .html file that I use to make the icon screenshot with all the icons.
Let me know what I can do to help.