The requirement is to ship the source in the preferred form for making modifications. That doesn't include standardized external tools, but it surely includes the build instructions (with things like which versions of the tools to use) and test suite (and indeed git history - mjg59 has disagreed with me regarding that before, but I don't think he gave a rationale) - those are things you'd definitely want to have for making modifications.
That would be another options, yes, though I don't think I've seen many employ source-available while also giving access to a working build chain/script.
Not having to add autotools to a BuildRequires is nice, but hardly the end of the world as a package maintainer. I agree though, the contents of the repository at a git tag is not necessarily a source DISTRIBUTION - which is what most people who are compiling your software would want - especially when many of them probably don't know the autotools incantations required to generate the configure script.
Maybe you don't want / you do not have the chance to have sources and build tools installed on your production server and you trust mtier to build the patched sources for you.
I find it very useful.
You do have to build it from source, but the documentation for how to do so is luckily quite good, and there's a dedicated channel in the Discord server for helping people with build issues if you run into any problems.
You're obviously not obligated, but I'd encourage you to try building it if you're interested!
The biggest reason is in case the original source goes away (the author removes a particular version for example). A lesser reason is to make it easier for others to get up and running without needing the build tools.
I tend to leave them out if it's a personal, open-source project. For a commercial project I tend to check them in.
You're totally right on the path to the source code. The build scripts, as typically run by a developer, should actually do two things: 1) build the code into binaries and 2) deploy those binaries on the developers machine so he/she can easily test it. Builds on official build machines shouldn't be putting the builds into the hard coded location, and so shouldn't do the second thing. I haven't started discussing the difference between build scripts and deploy scripts, but that's essentially the difference I'm referring to here.
Yeah but those steps should be part of the normal build process. If you have to use weird tools (e.g. autotools) to generate your "real" source code, I'd say the problem is those tools. Also. Seriously. Autotools? In 2016?
I don't follow. In my experience setting up a build environment and changing a couple lines of code provides a lot more control (and is a lot easier) than rewriting the whole thing from scratch or ditching it entirely for something else. If your distro's package manager supports source builds then you probably don't even need to use tools like GNOME Builder to make quick modifications.
reply