I hope I’m in the right place here, otherwise do let me know and I’ll move the topic to the appropriate place.
I was wondering what the best way is to let maintainers of the official repos know about issues with a certain app version and maybe hold out updates for that app a little longer.
As a very straight forward example: I’m using maven to build Java applications. I recently had to set up my dev environment on macOS, getting the latest version of maven, which is 3.9.7. Turns out this version brings issues trying to build JavaFX applications. I was wondering why it worked on both my Manjaro machines and then got confirmation that the Manjaro repo still holds maven 3.9.6 which doesn’t cause the aforementioned issues.
Now I don’t know if suggesting to skip version 3.9.7 or holding on to 3.9.6 for however long it might take to fix the issue is a good idea. But at least I’d like to inform the maintainers about it.
More info and confirmation on this issue can be found in this stackoverflow post (I can’t post links, sorry about this): https://stackoverflow.com/questions/78542808/maven-project-fails-to-resolve-javafx-dependencies
So yea, how do I best go about this? That’s the first time I would interact with maintainers this way other than reaching out a single time to a flatpak maintainer of a rather niche flatpak, so I’m not aware of the implications on how to get in contact with the busy folks for the official repos. Any advice would be greatly appreciated.
New users are not permitted to post active links but can post an inactive link in preformatted text - Posting links in forum
There has been a lot of related topics over the years - in some form they have all evolved around being able to keep the system at a certain level, install the same set of packages airgapped systems or sync a system without internet connection.
The blunt and direct TL:DR
Probably not going to happen
Likely not what you were looking for - you are the system administrator - you are free to handle it as you see fit.
Manjaro provides a branching buffer stable ← testing ← unstable, where unstable is equal Arch Linux stable.
This is likely why you are still in a sane state of mind regarding your question.
To keep yourself in that sane state - you have a couple of options
This is a limited option and it shouldn’t be active for a too long timespan.
custom mirror
You can keep your system at a certain level by creating your own mirror - that mirror does not have to be public - you create it just to keep your sanity.
This option can be used for a longer period of time. It allows you to sync new packages to your system matching a status quo. To move the status quo - when your depending package(s) is in an acceptable state, then - to sync your mirror - you run the sync script described below - then sync your system(s) using your portable mirror.
Project was initially created with IntelliJ on Linux and working on any Linux machine without issues
However, trying to run mvn clean install on Windows or macOS on the project will always result in the following error:
I’m totally fine with this answer and to be honest I already expected as much. Don’t get me wrong, I understand Manjaro as rolling distro just as any other and the fact that it’s “nearly” bleeding-edge made me choose it over Arch. So I’m glad for the branching buffer to at least get a chance to identify issues before it hits stable.
I’m just not aware on how the team internally handles how versions are elegible for a push to stable and when. So I thought maybe issues like this could be a reson not to push to stable for a while as I’m sure I wouldn’t be the only affected. But I’m also aware I might be in a minority.
I’ve got a couple options to keep the maven version I need, but I appreciate the additional options you’ve mentioned, so thanks for that! Always good to have more options to resort to.
Edit: The issue for maven has been reported in the meantime for both maven and OpenFX:
One of the many features that sets Manjaro apart from other Arch-based distributions is that it uses its own dedicated software branches, rather than relying on those provided by Arch itself. In fact, to ensure continued stability and reliability, Manjaro actually uses three distinct branches:
Stable branch: The packages that come to stable have gone through roughly a couple of weeks testing by the users of the Unstable/Testing repos, before they get the packages. These packages are usually free of any problems.
Testing branch: This is the second line of defense. Being a larger number of users than those using Unstable, they refine the work done prior to them by providing feedback on the packages they recieve on updates.
Unstable branch: Unstable is synced several times a day with Arch package releases. Only a subset of Arch packages are modified to suit Manjaro. Those that use Unstable need to have the skills to get themselves out of trouble when they move their system to this branch. They are the Manjaro users who are most likely to need to use such skills. Due to the feedback from the users of the Unstable repo, many issues are caught and fixed at this level. Although the very latest software will be located here, using the unstable branch is usually safe but - in rare cases - may cause issues with your system!
Thanks, I do get the gist of the different branches, but I couldn’t tell what would be considered “usually free of any problems” in consideration of this particular maven issue as it would break JavaFX project builds.
In the meantime it turned out the issue is on OpenFX side rather than maven, but I wouldn’t know if this would be considered enough of a problem not to move this particular maven version to stable after testing. That’s what my question was originally about, but I guess that cannot be generally answered, as I think this is decided on a per-case basis.
Either way, thank you both for all the additional infos, it’s always good to learn more.
regarding your question.