Thanks for the clarification. I assumed that a new compiler version would add new features like a new optimization mode and not change the optimization modes that were in-place when the source code was previously compiled.
tom kosvic
I’ve tried to make zypper dup but it takes like 5or 6 hours and my device had very low speed so I tried to make
sudo zypper dup -d
And after it finished I made
sudo zypper dup
And it took about 15 to 20 mins!
1 Like
I did not change the solver.cleandepsOnRemove = false but I use the --clean-deps flag at the command line or via switch in Myrlyn. I check the transaction details, and if vital packages or half of the desktop would be removed, i let the package installed.
This is quite usefull when you only want to test a new app or try it out. Install package XYZ. It installs 12 dependencies. You don’t like it and want to uninstall it. Use the --clean-deps flag and check the summary:
- it wants to uninstall 13 packages (XYZ+12 deps). Good, proceed on uninstall.
- it want’s to remove half your desktop? Stop and check deeper
2 Likes
You’re welcome. Understanding how software builds work can be complex and takes some expertise. I’m not a build service wizard, but I’ve been compiling code here and there in various languages for several decades now.
I can see how, for someone who doesn’t spend a lot of time building code, this might be more difficult to imagine. 
I have been compiling code since FORTRAN came into existence in the late 50s. I have done it as necessary to support engineering efforts but not as my main avocation. To this day, I will try to compile source code before reverting to flatpaks, appimages, etc.
I am trying to compile simgear/flightgear as of this moment to have my own latest version.
tom kosvic
Then you lost a bet. Why do you think “reproducible builds” are (still) the exception?
I am not familiar with the term “reproducible builds”. I will have to look that up.
I still think that if you give a newer updated compiler version the same source code and the same compiler/link command-line that you gave to the older version compiler that you will get the same executable code as with the older compiler.
@tckosvic a new flag has/was added… See the Factory Mailing List which Tumbleweed users should keep an eye on…
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/ZVPLNOFLHL7EUPZTQ2W5ZNL2RPG4IZMW/
That is simply not the case with modern compilers. But, as I explained earlier, you can certainly compare the checksums for earlier versions of the same packages and see that that’s not the case.
This is an instance of what you “think” not aligning with reality. In cases like that, I’m going to stick with what reality demonstrates. 
C and C++ compilers are a lot more complex than a FORTRAN compiler. (I was a CS student in college, and before that, I was an aeronautical engineering student who had to learn FORTRAN. I spent time during my college years looking at the internals of the Sun C++ compiler.)
Sometimes even compiling the same code with the same version of the compiler will yield different results - as knurpht said, “reproducible builds” are still the exception because there are deterministic elements of the build process that affect the output, and controlling those can be difficult with complex builds.
We’re not talking about something that’s a single file build here; we’re talking about something with thousands of source files and numerous dependencies.
1 Like
OK, I will let this be. I started in an era (during Apollo program) where the problem definition, the source code, the fortran language statements, the compilers, the linkers, and the OS were all evolving simultaneously and concurrently. You had to specify the fortran build version you wished to have your code run on; some didn’t compute properly, e.g. , at times Santa Barbara fortran didn’t run but Minneapolis fortran did. I have experienced how difficult it is to just move to a new compiler but at that time specified compiler settings were consistent across versions.
I will concur with you guys and update my thinking.
thanks for the info, tom kosvic