Replies: 3 comments 31 replies
-
|
We prefer to keep it in Alpine, but have no problem maintaining it ourselves if you don't want to. |
Beta Was this translation helpful? Give feedback.
27 replies
-
I, and other Alpine contributors have made numerous good faith attempts to discuss plans for upstreaming improved functionality into OpenRC over the years. These attempts have largely been met with indifference, or statements like "OpenRC is a Gentoo project." I was, and remain, hopeful that @williamh is actually interested in getting these things upstreamed. While our needs have outgrown what OpenRC is capable of providing, we are still willing to work with OpenRC, as we will likely have to support OpenRC-based configurations until at least 2025. Lets focus on moving forward, instead of passive-aggressive statements, as that does not accomplish anything constructive. |
Beta Was this translation helpful? Give feedback.
-
|
@cromerc Revisiting this after sleeping on it, I think that, as others have noted, this thread got derailed because of a series of misunderstandings. To that extent, I would like to apologize for throwing you under the bus. I felt like you were attempting to derail the conversation by saying that the concern I was expressing was not legitimate, and so I approached this from a position of being somewhat annoyed. Accordingly, I apologize for my harshness last night as a result of that frustration. @williamh Thank you for merging #445 and #446. What do you think about keeping OpenRC 0.44.x as an LTS branch until muon is capable of building OpenRC? We would be willing to participate, both in terms of manpower, and I would personally be willing to donate in order to support the maintenance of OpenRC 0.44.x as an LTS branch. |
Beta Was this translation helpful? Give feedback.
-
Thank you very much for your apology. I had no intention of derailing the conversation nor saying that your concern wasn't legitimate. I apologize if you felt that way. Truly a misunderstanding from the use of terminology in our different projects. I also too maintain the bootstrap scripts for Artix Linux which in turn is based on the bootstrap scripts from Arch Linux but modified to work with OpenRC, runit, s6, and suite66 inits. And the way that the alpine(now that I have seen its bootstrap code) and artix/arch projects do their bootstrapping process is done is completely different even though they share the same terminology. I am not one to hold a grudge and think it is important for the people working on distros that do not use systemd to be able to work together to improve the various inits and am always open for collaboration to improve said distros and their software. Again, thank you very much for this. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, lets focus on the future. Sorry about it. ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
@kaniini You're welcome, I had no problem merging those. :-) I'm sure we can work something out for keeping 0.44.x around for a while. The way we normally operate is, we fix bugs in master and back port important bug fixes to the most recent release branch. I guess the question is, how long would you want bug fixes to continue being backported to 0.44.x? Back porting may get a bit tricky once the source tree gets rearranged, but this is where you could help, or really for any back ports that I miss you can do this. Feel free to open prs against the 0.44.x branch and put something like "back port" in the title so they will stand out. I haven't looked at muon yet, how far off is it from being ready? I might download it and take a look. Also, I don't know who told you in the past that OpenRC is a "Gentoo" project, or gave you the impression that we ignore patches, but I want you to feel different going forward. :-) What are your downstream patches like, do you have anything that you think we can merge? |
Beta Was this translation helpful? Give feedback.
-
|
Please port the gnu --prefix and --libdir options to meson before removing the gnu make build system. I opened Issue #474 with my reasons for this request. Thanks! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@kaniini After much effort (the final missing pieces more or less were string.to_lower, vcs_tag, add_install_script, shared libraries and after discussion in #mesonbuild ~lattis volunteered to get this working), I think muon can now replace meson for building openrc. Building openrc from the latest git commit to muon: Can you confirm that it meets your needs? |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
@eli-schwartz @kaniini Can you please test with openrc 0.44.8 also? The build system at that release should be the same as the master branch, but if you can verify that it works as well this would be good. |
Beta Was this translation helpful? Give feedback.
-
|
Branching off a maintenance branch, and then copying over every commit from the master branch verbatim but with different commit sha1 hashes, is a code smell. (This describes the history of 0.44 through 0.44.4 until the first commit that wasn't cherry-picked to maint.) I'm sure it builds fine. |
Beta Was this translation helpful? Give feedback.
-
|
@eli-schwartz I'm not quite sure what you mean about a maintenance branch. All of the 0.44.x commits are cherry-picked from master. |
Beta Was this translation helpful? Give feedback.
-
|
Right, 0.44.x is a maintenance branch and it's a code smell -- and additionally defeats the advantages of git's excellent branching model -- to cherry-pick every single commit from master. Customarily, projects will release maintenance (semver patch) releases directly from master as long as all commits therein are worthy of it, until they reach commits that should not be in 0.44.x, and then branch to 0.44.x at the point of divergence. Rather than maintaining the same commits twice in different codebases. I'm not particularly interested in testing "literally the exact code but it has different sha1 hashes". I got close enough to figure out that it was essentially the same code minus the ability to decisively track which commit in master is available in which release, and then figured I did my due diligence by testing master. To be honest, I am not an alpine linux user, and I'm not an openrc user either. :) I am, however, a meson developer -- and for this reason I find myself interested in how projects are using meson, and I'm especially interested in muon because it is a general solution to a problem that isn't alpine-specific and which is acknowledged in our (meson's) FAQ. So, I have contributed a fair bit to muon as I think it's valuable to have multiple implementations of the meson build language and especially valuable to have one that is easily bootstrapped from an OS that starts off with only a C compiler. As I'm aware that some users of openrc are concerned with the bootstrap story of openrc, I figured it would be useful to raise awareness that there is some exciting news and muon has progressed enough to be able to be that bootstrap method for openrc. But I really have no way to test anything other than the fact that it builds and installs the right set of files. I don't have an OS which uses openrc to boot. I also have no idea what any distro (alpine or not) does to patch it. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey all,
OpenRC 0.44 has adopted meson as its build system.
I would like to remove the old GNU make build system sooner than later to avoid maintaining two build systems.
If no one objects, my proposal is to keep it available for the 0.44.x branch but remove it for newer versions.
Let me know if you have concerns.
Thanks,
William
Beta Was this translation helpful? Give feedback.
All reactions