use of gtk-update-icon-cache?

Enrico Scholz enrico.scholz at informatik.tu-chemnitz.de
Fri Apr 29 13:40:18 UTC 2005


bugs.michael at gmx.net (Michael Schwendt) writes:

>> > %post
>> > # update icon themes
>> > touch %{_datadir}/icons/hicolor
>> > if [ -x /usr/bin/gtk-update-icon-cache ]; then
>> >   /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor
>> > fi
>> 
>> Stop, before applying such scriptlets: There must be appended an '|| :'
>> after the 'touch' and the 'gtk-update-icon-cache' command. When %_datadir
>> is in %_netsharedpath and mounted read-only therefore, the command and
>> the entire scriptlet will fail.
>
> Package installation would fail miserably in that case, because the
> package could not install any files into %_datadir beforehand.

Wrong; you missed the %_netsharedpath part ;)

The scenario is this:

Host A:
* exports /usr via NFS
* /usr is mounted read-write there
* installs the superset of all packages on hosts X, Y and Z


Hosts X, Y, Z:
* mounts A:/usr readonly
* has a %_netsharedpath of /usr


Now, when A installs a package owning /usr/bin/foo it will be installed
physically and is available on X, Y and Z. When X installs the same package,
it will be added to the database but not installed physically. E.g.:

| $ rpm -qs <the-package>
| net shared    /usr/bin/foo


> For exported file-systems, you would only install packages on the file
> server, where the install locations are not read-only.

You miss the fact that most packages ship files under /etc or /var also
which can not be shared, do registration tasks in the %scriptlets or are
dependencies of other packages. Therefore, packages must be installed on
both the fileserver and the clients.


jbj wants to solve this by attaching actions to certain filetypes (and
obsoleting most %scripts by this). I am a bit sceptical about this and
would prefer a lower level mechanism (like this in bug #51193). See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=51193 for more
details or search for 'mount' and me in bugzilla ;)





Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20050429/54d189df/attachment.sig>


More information about the fedora-extras-list mailing list