I am not going to reiterate here why this is mostly a bad idea, at least/especially with Travis CI scripts. I can't repeat myself often enough that there are ready-to-use, copy-paste snippets in the docs already, can I?

For the average developer running something local is important and also ensures portability and independence from CI platforms. You don't want to bind yourself too much to proprietary infrastructure.

You can copy bash scripts doing all you need in https://docs.appimage.org/packaging-guide/from-source/native-binaries.html#examples, these also elaborately explain what they do in every step. That's not as cryptic as an uninspired Travis CI yml thingy that encourages people to bind themselves to proprietary services and don't explain e.g., why tools need to be run twice, etc. The scripts have been written with great care, and there's even a snippet that shows how to run them from Travis, https://docs.appimage.org/packaging-guide/from-source/native-binaries.html#travis-ci.

My mantra is that I don't want to hand out weird scripts which people cannot maintain themselves because they don't understand them. Also, people who show no intent in understanding them will just come back to me and expect me to fix their issues. That binds a lot of time and is no fun at all. Therefore my idea is to give them resources they can copy-paste if they don't want to invest 5 minutes into reading the docs, but at least then have some starting points to debug their issues. Also, I can run these scripts myself if I should decide to help with starting problems on my own computer, and don't have to wait for something like Travis that takes ages to build something and also is impossible to debug runtime failures on.

Your linuxdeployqt script there suffers from so many of the issues I just mentioned, hence sharing it with anyone is not just a bad idea for sustainability reasons (i.e., having them maintain it; they'd rather remove it if they lose interest), but also gets you into a situation where everyone will just come to you to fix issues that are easy enough to solve by themselves, e.g., wrong paths.

I haven't had a single linuxdeploy user complaining about not being able to resolve an issue unless there was a bug. And even that happens only every couple months.

Fast links to copy-and-paste snippets #29

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions