[Breeze] [Bug 445489] New: Light theme icons randomly get installed in breeze-dark theme

[Andreas Ferber]

https://bugs.kde.org/show_bug.cgi?id=445489

            Bug ID: 445489
           Summary: Light theme icons randomly get installed in
                    breeze-dark theme
           Product: Breeze
           Version: master
          Platform: Compiled Sources
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: Icons
          Assignee: visual-design at kde.org
          Reporter: af+kde at chaos-agency.de
                CC: kainz.a at gmail.com
  Target Milestone: ---

SUMMARY

After installation the `breeze-dark` theme randomly contains icons from the
`breeze` (light) theme instead of the actual dark mode icons.

The problem was introduced by the following two commits:

*
https://invent.kde.org/frameworks/breeze-icons/-/commit/d9a5af79a559a2ecff118e580bd560f2d50353c4
*
https://invent.kde.org/frameworks/breeze-icons/-/commit/dda2316fc37156366def936d04029463087a153c

The intention seems to be to install icons from the light theme into the dark
theme that are missing from the dark theme (eg.
`actions/16/color-management.svg` exists in `icons` but not in `icons-dark`). 
This was done by installing the light icons into the destination first probably
with the expectation that any icons that actually exist in the dark theme will
then get overwritten with the dark version.

However, cmake when installing files only compares timestamps when deciding
whether a file is already up-to-date in the destination, and skips copying the
file if the timestamps match (unless the `CMAKE_INSTALL_ALWAYS` environment
variable is set). It *does not* compare file size or contents! The result is
that whenever the light theme icon file and the corresponding file in the dark
theme happen to have the same timestamp (as is often the case as git doesn't
preserve timestamps when checking out files, so if you say do a fresh clone on
a fast disk where the checkout runs in under a second all files have the same
timestamp) then the "preseeded" version from the light theme doesn't get
overwritten with the dark theme version, so you end up with the light version
of the icon in the installed theme.


STEPS TO REPRODUCE

Run the following commands in a shell:

---------------------------
git clone https://invent.kde.org/frameworks/breeze-icons.git
demo-breeze-icons-bug
cd demo-breeze-icons-bug
# ensure two files have same timestamp
touch -r icons/actions/12/object-fill.svg icons-dark/actions/12/object-fill.svg
mkdir build inst
cd build
cmake ..
make  install DESTDIR=../inst
cd ../inst
diff -u usr/share/icons/breeze{,-dark}/actions/12/object-fill.svg
---------------------------

OBSERVED RESULT

The diff at the end of the commands above doesn't output anything, ie. the
files are identical.

EXPECTED RESULT

The diff should show the same differences as if you made a diff between
`icons/actions/12/object-fill.svg` and `icons-dark/actions/12/object-fill.svg`
in the source tree:

---------------------------
--- icons/actions/12/object-fill.svg    2021-11-14 15:35:50.214936474 +0100
+++ icons-dark/actions/12/object-fill.svg       2021-11-14 15:35:50.214936474
+0100
@@ -1,11 +1,11 @@
 <svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" width="12" height="12" id="svg3049">
     <defs id="defs3051">
         <linearGradient id="linearGradient4234">
-            <stop style="stop-color:#232629;stop-opacity:1" offset="0"
id="stop4236"/>
+            <stop style="stop-color:#eff0f1;stop-opacity:1" offset="0"
id="stop4236"/>
[...]
---------------------------

ADDITIONAL INFORMATION

Digging through cmake it seems that the environment variable mentioned above
(CMAKE_INSTALL_ALWAYS) is the only way that "optimization" in cmake can be
disabled, and I don't think there's any way to set it from within
CMakeLists.txt in a way that it affects the currently running cmake . So I
think unless you want to tell people that they must set this variable before
installing breeze icons reverting the commits listed above is the only way to
fix this.

-- 
You are receiving this mail because:
You are the assignee for the bug.