I am not including the usual check lists, because my issue isn't a bug, per se, but what I see as a flaw in the general design of the Linuxbrew package manager.
Many times I notice that there are underscore versions which don't actually reflect changes to the application, python3 3.6.4_2, for instance. These underscore versions present problems during upgrades. I already have python3 3.6.4 installed. brew outdated will list python3 (3.6.4) < 3.6.4_2, and brew upgrade will reinstall python3 3.6.4. I have a script which runs brew upgrade so that the applications which I have installed are up-to-date. The underscore versioning is creating a headache. There should be a way to segregate the "linuxbrew" versioning from the actual application versioning for upgrade purposes.
It may be that I have to go through and upgrade applications individually or in my script I may have to loop through and parse brew outdated so as to only upgrade to versions which represent actual application versions. I've noticed that this isn't a complete solution, however. I've noticed in the past that if I upgrade an application and a dependency of that application is also seen by brew to require an upgrade then that dependency is also upgraded. I distinctly remembering this occurring even if the dependency had been pinned.
Maybe I'm missing something. Maybe I don't understand the reasoning behind the underscore versioning, and how it's supposed to work. Maybe I'm being daft. Can someone please explain this to me, or can we work on some sort of solution?
Thanks and cheers
The version part after the underscore is called the formula revision in brew vocabulary. The revision is bumped when the formula is changed in a way that requires users to upgrade, such as rebuilding against new versions of dependencies, or possibly fixing a bug in packaging.
I'm closing this issue, but feel free to comment or ask more questions.
@sjackman
I'm confused. "The revision is bumped when the formula is changed in a way that requires users to upgrade" I've installed Python3 3.6.4, and it seems to work just fine. It seems that Python3 3.6.4_1 and Python3 3.6.4_2 only represent changes in the rb to the sha256 hashes for the bottles. Does this mean that the previous bottles were wrong and not working for people? Is there something wrong with my Python3 installation?...
$ brew info python3
python3: stable 3.6.4 (bottled), devel 3.7.0a3, HEAD
Interpreted, interactive, object-oriented programming language
https://www.python.org/
/home/linuxbrew/.linuxbrew/Cellar/python3/3.6.4 (8,622 files, 182.4MB) *
Built from source on 2017-12-22 at 06:35:26 with: --with-tcl-tk --with-sphinx-doc
If there isn't anything wrong with my Python3 installation, why should brew upgrade reinstall 3.6.4?
Thanks and cheers
For python 3, I made some changes lately for different reasons (due to changes with the x11 requirement). It may be that not all revision bumps are always needed, but I have no time to test this before bumping. Of course with infinite help from contributors, we would be testing this before. But as I am mostly updating the formulae alone, I sometimes take shortcuts. Please remember that we are an understaffed open source project, with contributors working on this during their free time.
So in 90% of the cases the revision bump is justified.
It also prevents some weird errors which we need to debug later if we had forgotten to bump the revision, which makes us loose even more time.
@iMichka
Thanks for your response.
@iMichka and @sjackman
Thanks for the tremendous effort that you guys put into Linuxbrew. I understand that things could be refined, but I am also grateful for the benefits that Linuxbrew, as is, provides to me. I will deal with the imperfections from my end.
Cheers
It seems that Python3 3.6.4_1 and Python3 3.6.4_2 only represent changes in the rb to the sha256 hashes for the bottles.
The most common reason for bumping the revision when there are no changes to the formula is to rebuild it the binary with new versions of its dependencies.
Most helpful comment
For python 3, I made some changes lately for different reasons (due to changes with the x11 requirement). It may be that not all revision bumps are always needed, but I have no time to test this before bumping. Of course with infinite help from contributors, we would be testing this before. But as I am mostly updating the formulae alone, I sometimes take shortcuts. Please remember that we are an understaffed open source project, with contributors working on this during their free time.
So in 90% of the cases the revision bump is justified.
It also prevents some weird errors which we need to debug later if we had forgotten to bump the revision, which makes us loose even more time.