Hey Martin, On 10.11.2021 21:08, Martin Michel wrote:
I think README files are valuable, it was completely my inattentiveness that I did not enable runscripts option and directly run `prt-get depinst` without having a look into the `prt-get info` first to discover hints about READMEs and pre-/postinstall scripts. I think some lazyness I was getting used to from other package management system fell on my feet here.
I think it would be great if others port maintainers would then chime in, it takes a commitment from all of those to handle their own ports and add these files and texts. I will think about doing that in the future, one more item on my ever so long to do list for CRUX..
Nevertheless, I also think it would help to emphasize or warn about the fact in the handbook. Because, yes, indeed it was my first reference but I somehow overlooked the importance of some "details".
Yep.. these „one liners“ I posted haven't been written by me, they have been around for quite some time, still they are forgotten very fast.. The way the ports system works can make it feel rough. The best way actually would be to have every port affected by bumped in their respective port release number. This way, everybody gets to update them as soon as the „breaking change“ is pushed. That's not easy to overview, really, and we do not have a CI in place that would notify us maintainers when such a change occurs.. so yeah, it's just humans after all, and that has been proven to be riddled by errors and irrationalities, and it's just a couple of people contributing to CRUX officially. Also keep in mind that optional dependencies are in no way handled by the ports system. Every tool will ignore the `# Optional: ..` line that seem to be adopted, and currently, nobody is working on these tools either, so they are purely there for the attentive reader to make their choices. To me, thats really what you sign up for when you use CRUX, it has never been different for me in over ten years and you just learn to watch out for certain things (e.g. poppler) or can understand what something means e.g. non existant la file that something links against ¯\_(ツ)_/¯
Hm, I do not know about libreoffice but could this not be solved by publishing two packages, a libreoffice-gtk3 and a libreoffice-qt5, each with specific build configurations? Or otherway around, is this really a CRUX issue or could this be fixed by a flexible build configuration which the libreoffice maintainers or developers should provide?
Buildoptions are available, but another package is just yet another package. Since I am the one maintaining libreoffice (among around 1000 other ports) people get to enjoy my flavor of the Pkgfile, propose their changes or maintain their own fork, because every other variation I maintain means I need to recompile the port once more in a clean container, which adds more time spent and no, thanks, I won't do it. It is the same ludicrous wish that maintainer would share their built packages.. Best thing I can do is to enable things optionally, but I need at least one default to reach my goal of having a Pkgfile that will install fine with depinst from a clean CRUX install, gtk3 is a sensible choice because firefox is the per se default browser used on CRUX, depending on gtk3, and there is no other real contestant to that despite qutebrowser, which probably won't have that many fans. What is on my to do list for libreoffice would be to split it up into individual packages and one group package that would install all, but a user could still make a choice if all he wants is calc or writer for example. If you want to participate and maintain Pkgfiles, be my guest, I wrote a little guide that is still a WIP and could use a few updates, but I don't have time to do that right now [1] It's rather trivial in most cases is all I can say anyway. Best regards, Tim [1] https://gist.github.com/TimB87/6cf010c0c10d67faf98ae03e62ffb029