Bug 166008

Well, if selection for box now contains yast2-theme-NLD, this bug can be invalid.

But maybe we can add Obsoletes: (well, not really required, because AFAIK this package was existing only in betas).

The icons in question which need to be symlinked to the hicolor theme, are:

yast-bluetooth
yast-scanner
yast-timezone
yast-users
yast-x11
yast-yast-language

This bug should be assigned to the person who packages yast2-theme-SuSELinux, not to me. i am reassigning to the yast2 maintainers. 

Yast2 maintainers, please let me know if you require anything from my team. 

yast2-theme-NLD.spec says:
Remove obsolete yast2-theme-SuSELinux (breaks build)

But looking at selectio package from /work/SRC/old-versions/10.1/all/selectio, it contains yast2-theme-SuSELinux.

My system was not installed cleanly, so I cannot exactly say, which package will install with box 10.1, but ut seems, that yast2-theme-SuSELinux.

But at least on OpenSuse Beta8, only yast2-theme-SuSELinux is installed.

Stanislav, the -NLD package should only be on SLED/SLES, and the -SuSELinux package should be in OpenSuse/SL10.1.

It would be really nice if we could just replace these two packages and use the artwork in the -NLD package exclusively, or fix yast2 to just use the icon theme for finding icons. The latter is ideal, but much more work to implement and get right.

This bug seems invalid to me:

every product has its own set of patterns or selections. They should use a single theme package there. File a bug reports against the product, do not try to compare contents of 2 distinct packages.

OK. Reopening with better description:

GNOME control-center (SuSE Linux box) requires proper icons in yast2-theme-SuSELinux.

These icons must be in the XDG_DATA_DIRS path and in hicolor theme.

You can take these icons from yast2-theme-NLD, where all these icons are present in /opt/gnome/share/icons/hicolor.

There is a reason why the SuSE Linux box uses a different icon set - or, rather, why SLED uses a different icon set than all other products. The icon styles are very much different.

I don't quite understand what this is all about. The yast2-theme-*.rpm don't have any notion of KDE, GNOME or any other desktop. The paths used are

%files SuSELinux
%defattr(-,root,root)
%dir /usr/share/YaST2/theme
%dir /usr/share/YaST2/theme/SuSELinux
%dir /usr/share/YaST2/theme/SuSELinux/control-center
%dir /usr/share/YaST2/theme/SuSELinux/wizard
%dir /usr/share/YaST2/theme/SuSELinux/wallpapers
%dir /usr/share/YaST2/theme/SuSELinux/icons
%dir /usr/share/YaST2/theme/SuSELinux/icons/48x48
%dir /usr/share/YaST2/theme/SuSELinux/icons/48x48/apps
%dir /usr/share/YaST2/theme/SuSELinux/icons/32x32
%dir /usr/share/YaST2/theme/SuSELinux/icons/32x32/apps
%dir /usr/share/YaST2/theme/SuSELinux/icons/22x22
%dir /usr/share/YaST2/theme/SuSELinux/icons/22x22/apps
/usr/share/YaST2/theme/SuSELinux/*
/usr/share/YaST2/theme/SuSELinux/control-center/*
/usr/share/YaST2/theme/SuSELinux/wizard/*
/usr/share/YaST2/theme/SuSELinux/wallpapers/*
/usr/share/YaST2/theme/SuSELinux/icons/*
/usr/share/YaST2/theme/SuSELinux/icons/48x48/*
/usr/share/YaST2/theme/SuSELinux/icons/48x48/apps/*
/usr/share/YaST2/theme/SuSELinux/icons/22x22/*
/usr/share/YaST2/theme/SuSELinux/icons/22x22/apps/*
%dir /usr/share/YaST2/theme/SuSELinux/testpage
/usr/share/YaST2/theme/SuSELinux/testpage/*
%doc %{prefix}/share/doc/packages/yast2-theme-SuSELinux


There is NO path that involves KDE, GNOME or any other desktop. If the desktops wish to reuse the YaST2 icons, this is the responsibility of the desktops, not of the theme package.

If we package GNOME or KDE paths in yast2-theme-*.rpm, what is supposed to happen if the respective desktops are not installed? Users don't want stray directory hierarchies, much less prominent (and very visible) ones like /opt/gnome or /opt/kde3. If I don't have KDE or GNOME installed, for sure I don't want any /opt/kde* or /opt/gnome directory on my system.

So if we really want or need those icons in /opt/gnome/..., we will need a separate package that handles this. Moving that to the yast2-theme package is an ugly hack and a packaging bug.

yast2-theme-NLD has a notion of GNOME (or exactly icon in patho of XDG_DATA_DIRS):
/opt/gnome/share/icons/hicolor

yast2-theme-SuSELinux has no notion of these icons and GNOME control center has a dumb icons.

That's what I mean with "packaging bug". You will get an /opt/gnome directory even if not one single GNOME application is installed if you only install that yast2-theme-NLD package. This is a bug.

So, how do we want to go along to handle this properly?

hicolor icon theme is not GNOME related, it's a generic theme. Icons can be in /usr/share/icons/hicolor without any problems.

We can fix it by:
- Modify XDG_DATA_DIRS to include YaST themes (there must be provided icon theme named gnome or hicolor).
- Provide these icons in standard paths.
- Modify control-center to search for icons in YaST paths.

> - Provide these icons in standard paths.

This is the best option I think. The icons need to be provided in an icon theme so that they may be found. If hicolor is not GNOME related, why do we ship it in gnome-icon-theme rather than its own package that installs to /usr/share, rather than /opt/gnome/share? Instead we have two desktops providing conflicting index.theme files for hicolor both in /opt/<desktop>/share/icons. This causes even more problems.

We could install the icons to /usr/share/icons/hicolor instead of /usr/share/YaST2/theme/$THEME/icons, and provide a symlink, but we then need rpm triggers to get rid of the /usr/share/YaST2/theme/$THEME/icons directory properly, as simply replacing a regular file with a symlink in rpm causes a cpio unpack error on upgrade. I am fine with changing the -NLD theme to do the same thing.

This would break everything else in favour of fixing GNOME's behaviour. We would have to change at least the YaST2 control center and everything KDE related.

Since this is a GNOME problem, it should be fixed on the GNOME side, not moved around to be everybody else's problem.

Why this solution will break everything in SuSE Linux 10.1, if it already works OK in SLED10?

/opt/gnome/share/icons is in the XDG_DATA_DIRS path, so it is visible to all XDG conforming applications searching for hicolor icons, not only to GNOME.

It would absolutely not break yast and kde. I've already tested moving the icons to hicolor and symlinking to that theme. It works perfectly fine. It doesn't break anything. The only issue is that on upgrade, the cpio unpack error happens, unless one adds an rpm trigger to handle replacing the directory with a symlink.

If we need symlinks, they will be the other way round: From whatever/hicolor/ to /usr/share/YaST2/theme/something. 

OK, I'm updating yast2-theme-NLD to simply symlink all the available icons for the yast2 theme to /usr/share/icons/hicolor appropriately, rather than only copying a subset over. I'm also adding an Obsoletes: yast2-theme-SuSELinux, so that you can't install both, as yast2-theme-SuSELinux needs to also provide these symlinks for the desktops. Here is the block that I use in the %install section to create the symlinks:

-----------------------------------------------------------------------------
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/hicolor/22x22/apps
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/hicolor/32x32/apps
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/hicolor/48x48/apps
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/hicolor/scalable/apps
cd icons
for dir in "22x22 32x32 48x48"; do \
  for icon in $dir/apps/*.png; do \
    ln -s /usr/share/YaST2/theme/NLD/icons/$icon $RPM_BUILD_ROOT/usr/share/icons/hicolor/$icon; \
  done; \
done
for icon in scalable/apps/*.svg; do \
  ln -s /usr/share/YaST2/theme/NLD/icons/$icon $RPM_BUILD_ROOT/usr/share/icons/hicolor/$icon; \
done
-----------------------------------------------------------------------------

Can you please do the same in yast2-theme-SuSELinux and add /usr/share/icons/hicolor to its file list? Thanks.

(In reply to comment #18)
> I'm also adding an Obsoletes: yast2-theme-SuSELinux, so
> that you can't install both

Shouldn't this be a Conflicts: instead? From my (very basic) understanding of RPM, an Obsoletes: means the NLD theme will _always_ replace the SL theme because it is it's "sucessor". I'm not sure if this is the intended behaviour here...

A "conflicts" will result in a dependency conflict dialog the user will have to resolve manually. "Obsoletes" definitely is the way to go here.

Rodney: Thanks, this block will certainly speed things up.

After repeated attempts to get this working, I now have this block in my .spec file:

mkdir -p $RPM_BUILD_ROOT/usr/share/icons/hicolor/22x22/apps
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/hicolor/32x32/apps
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/hicolor/48x48/apps
cd $RPM_BUILD_ROOT/@themedir@/SuSELinux/icons
for dir in 22x22 32x32 48x48; do
    cd $RPM_BUILD_ROOT/@themedir@/SuSELinux/icons/$dir/apps
    icons=$(ls *.png)
    cd $RPM_BUILD_ROOT/usr/share/icons/hicolor/$dir/apps
    for icon in $icons; do
        ln -s ../../../../YaST2/theme/SuSELinux/icons/$dir/apps/$icon .
    done
done


(there is no scalable/ subdir in the SuSE-Linux theme)

The code from comment #18 didn't work for me: Only the 48x48 icons were symlinked successfully. For some weird reason, the 22x22 and 32x32 dirs only had (broken) symlink of the 22x22 or 32x32 dirs, respectively. I fear this will be the case for the NLD theme, too, but probably nobody noticed so far. 

Rodney, you might want to check this (simply grab that RPM from STABLE and use "unrpm" to unpack it somewhere and have a look what is actually inside).

It might have something to do with the quoting in

    for dir in "22x22 32x32 48x48"; do

this will treat the content of the quotes as one single item, not as three separate items. 

BTW most the backslashes are unneded in a spec file.

Doh. Right about the quotes. Sorry about that. The NLD theme indeed had the same issue. Thanks for pointint it out. I've submitted a fixed version of that theme now.

See also bug #247294