Open cromerc opened 6 years ago
guinux
commented
6 years ago First I hope you the best with your project. Then, as I code pamac on my free time, understand that adding support for other distros than Manjaro or Arch is not a priority even if adding build options id not a bad idea. If you or anyone else want work on it, I will give him/her, of course, all the help I can.
sudoBash418
commented
6 years ago @guinux So, are custom builds going to be implemented? Or at least #299? (The option to turn off generic package names + icons)
cromerc
commented
6 years ago Sorry for the late reply, been rather busy. I have implemented a proof of concept in the 5.x.x fork I did at: https://github.com/cromnix/pamac-classic If all goes well and works correctly this can be implemented on the parent Pamac here as well and I am willing to help out with it's implementation if you think it would be beneficial.
Here is the commit where I implemented the new build system: https://github.com/cromnix/pamac-classic/commit/235c95aa2b8bbe519c1074fa455c5ed0257ea1de
It implements AutoVala with CMake to detect and produce all of the Makefiles to build the project and then applies the correct parameters to build it the way the user wants to have it built. It also does checks to verify that all dependencies are met before it can be built which is great for sanity checks.
I only implemented 2 flags, one to disable the AUR, and another to build the KDE tray icon instead of the GTK3 icon for Gnome. When AUR is disabled it removes all traces of the AUR from the Pamac applications which of course generates smaller binaries with better performance.
Here is an example PKGBUILD that you can use to play around and see how it works: https://gist.github.com/cromerc/e4f0e69a25d8f6a5fb26b201b741e855
Hopefully you can give me some feedback or improvements that can be done with this.
guinux
commented
6 years ago Sadly, it seems we work on the same feature. I also work on added a build system but I choose meson. I planned to release it last week but the resolution of #331 was a priority. I will push it so you can have a look.
cromerc
commented
6 years ago If you or anyone else want work on it, I will give him/her, of course, all the help I can. Sadly, it seems we work on the same feature.
Looks like we both had the same idea, but with different implementations. I had started it because you had mentioned that if anyone else wanted to work on it you would help. Because of that I had assumed that you would not be implementing this yourself.
The reason I had chosen AutoVala was because it automatically reads the Vala files and determines all dependencies, library linkage, flags, etc. Because of that I don't have to manually create the CMake files. The CMake files are created automatically when AutoVala scans the project. AutoVala also has Meson support. AutoVala can actually generate both CMake and Meson files for the project with 1 command, the only downside is that AutoVala only recently added Meson support and is still prone to some bugs. That is the reason I decided to just start with CMake first, I can generate the Meson files later at any time I choose to give users another way to build it.
I just gave your meson implementation a try and it looks nice. The next important step would be to add conditional preprocessor options into the source files for Pamac.
guinux
commented
6 years ago Sorry for the double work. I also worked on a build system to make pamac more "serious" and for the features it gives. With meson the build speed is also improved. For the conditional preprocessor options if you want to work on it, I will let you do, without double work this time :)
cromerc
commented
6 years ago I don't consider it to be double work. I had forked the 5.x.x release of Pamac for a very specific reason, basically to keep it as simple as possible without a lot of extra app store features. pamac-classic will be just stay a basic package manager, nothing more. I only plan to backport bug fixes, and small features into it.
As far as the preprocessor options, I will do it for the Pamac project as well. I already did the disable aur preprocessor option in pamac-classic, so I already know how to do it again in Pamac. :)
Before I get started on it, are there any big changes to the code coming up? It requires me to change most of the source files of pamac to implement the ability to disable the aur and would make things complicated if conflicts arrive from big changes to pamac. If there are going to be any big changes I should wait till they get pushed before starting.
guinux
commented
6 years ago Ok so I will tell you when Appstream support is complete.
I know that pamac is primarily used under manjaro, however it is also usable under various other distros that use pacman as well. That being said, I believe that builds should be configurable based on what features are wanted or can actually be used by a given distro. For example:
As an example I have started a new distro that has pamac in it, it is not however a fork of arch linux, it was built based on linux from scratch but uses pacman as it's package manager. Due to this, pamac works great, but AUR is incompatible since none of the packages in the distro come from arch linux which means many dependencies can't be resolved or don't work properly. So disabling AUR is crucial for the distro. I do have appstream data implemented for pamac, however there are very few packages currently available in the new distro which means some categories don't work, so being able to disable categories would be needed. Lastly flatpak and snaps are definitely not implemented nor supported since this isn't an arch linux based distro, so the ability to disable that would be great as well once it is implemented.