Dear Martin, On 07.11.2021 21:25, Martin Michel wrote:

On the other hand, being a CRUX newbie and just looking at the error, it was not obvious to me that this results from not having run various pre/post-installation scripts in the docbook dependencies.

True, but there is no real good way for us to actually step in there and make this more obvious, unfortunately. READMEs along Pkgfiles are often ignored as well, so writing them might feel like a useless task, it might be better to make this more clear and explain the severity in the handbook.

So far, CRUX is really awesome and I am wondering more and more why package (and system) management I have experienced in other distributions had to be so complicated/opaque/unsatisfactory.

Well, it has it's own shortcomings. You can't say anywhere e.g. to build libreoffice with qt support and without gtk3, it will always build gtk3, and optionally enable qt support when you have qt5 installed, or other scenarios. CRUX chooses to be simple, but that also means that you might need to dig into stuff when you expect/want certain stuff, because best we can do is enable stuff optionally (extreme examples might be ffmpeg and mpd), but if you uninstall any of that, your install might break. Few further tipps: - If you haven't already found out about revdep, this is something you might want to look into (opt/prt-utils). - Even CRUX veterans often forget simple procedures, so your hick up today wasn't anything special ;-) Another thing you might trip over in the future is when ports (usually when changing from autotools to something more modern like cmake or meson) stop providing la files, the following script is something I have stored as a shell function to use at convenience whenever neccessary: ```sh rebuild-lib() { prt-cache update -fr \ `for f in $(/usr/bin/grep -lr "$*" /usr/lib/ 2> /dev/null | sed 's|.*/||'); \ do prt-get fsearch $f | /usr/bin/grep '^Found in' | sed -e 's|.*/||' -e 's|:$||'; \ done | sort -u | xargs prt-cache isinst | /usr/bin/grep -e 'is installed' | awk '{ print $2 }'`; ``` It takes the la file, say `libfreetype.la`, and will find any library that references the la file (it's just autotools trash) and rebuild it. See the following commit from not too long ago [1] and see that libfreetype.la is not longer around [1]. Glad you like your experience so far! All the best, Tim [1] https://crux.nu/gitweb/?p=ports/opt.git;a=commitdiff;h=0a0506972c45a330511ca...

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

Hey Martin, On 17.11.2021 21:37, Martin Michel wrote:

sorry for the late response but I had to pause with CRUX for a few days.

Don't worry.

I already started to create a bunch of own packages for some programs I like or regularly use and which I want on my fresh CRUX installation.

Look through core/opt/contrib packages for the best examples. I just put that together when i had a few free minutes but since then never had the time to revisit the guide, even though I want to. Some things I do at least have changed, out of the top of my head, I know pretty much put lto and pie on everything meson.

Hm, I would not say it is "trivial" because now I know that my first attempts of creating packages only scratched the surface of what is possible and recommended. On the other hand, with only minor fiddling, packaging worked very well so far. And now I have a perfect reference to improve and look for answers to some questions. And yes, agreed, all in all CRUX packaging is really not daunting and follows KISS in an exemplary manner.

When you look at a few core/opt/contrib (and compat-32 if you need any of that) you will see that most of them are very very similiar. With that in mind, it narrows down to providing a good basic depends on line as well as a proper footprint, IMO. There is only a few odd ones that really mean work after they are intially are set up.

I am wondering, how do you manage to maintain 1000 packages and more? That is really impressive! I mean, how do you track which packages are subject to updates, read release notes, etc. How much time, automatization and energy do you put into this task?

Abusing coffee and unhealthy sleeping habbits. Like mentioned above, it's often just a number bumping game as well as rebuilding these ports in a container. I have a few scripts to help around the task. I am subscribed to mailing list, watch git repos, monitor some rss feeds and there is repology too. I used opt/ck4up for a long time, but writing a lot of rules in ruby regex just isn't my jam :) But yes, it grew that now it takes a considerable amount of my time. So far, there have not been people that step up and want to officially contribute, and I'd certainly be considering transfering ownership for some of my ports if there ever was somebody seeking to help out. Future plans would involve putting together a CI that would build packages in a clean container, gitlab, buildbot, whatever, and automate it through git (on push hooks for prs generated by a bot maybe?). I am unsure if we could do that with our own ressources, and as far as I know there is no flow of money to the project so paid solutions (for me) are off the table for now. In short, all I am ever saying is we need more people to actively contribute to CRUX.

Concerning your invitation, give me some time to get familiar with CRUX, packaging etc. If nothing unexpected happens, I definitely plan to stick with CRUX and would like to share my package repository and experiences here as well.

Don't worry, I am easy on telling that to people because of what I explained above. I am more of a "with the door in hand through the wall" kinda guy. I am glad you enjoy your experience so far! Best regards, Tim