gallery2-2.3-3.fc10.noarch on F10 x86_64 updates-testing has error

[stan]

Jon Ciesla wrote:
>> Michal Jaegermann wrote:
>>> On Mon, Feb 09, 2009 at 01:04:31PM -0700, stan wrote:
>>>>>> error: unpacking of archive failed on file
>>>>>> /usr/share/gallery2/lib/smarty: cpio: rename
>>>> Here is the output of the rpm command:
>>>>
>>>> $ rpm -V gallery2
>>>> .......T  c /etc/gallery2/config.php
>>>> .......T  c /etc/gallery2/login.txt
>>>>
>>>> Seems to be saying a timestamp error for a configuration file.
>>> Configuration files tend to have timestamps different from originals
>>> as they are, well, configurations and possibly adjusted during
>>> or after an installation.
>>>
>>> It appears that an update was abandoned but you likely have now a
>>> dangling link, or links, in /usr/share/gallery2/lib/.
>>>
>>>     Michal
>>>
>> Yes, you are right on the money.  A bunch of dangling links in that
>> directory like
>> lrwxrwxrwx 1 root root   16 2009-02-08 18:23 smarty;498f8598 ->
>> ../../php/Smarty
> 
> So it did't get far enough to pull in php-Smarty?
> 
Everytime I ran an update it created a new link in /usr/share/gallery2/lib/.

lrwxrwxrwx 1 root root   16 2009-02-06 10:57 smarty;498c79e9 -> ../../php/Smarty
lrwxrwxrwx 1 root root   16 2009-02-06 15:38 smarty;498cbbee -> ../../php/Smarty
lrwxrwxrwx 1 root root   16 2009-02-08 10:19 smarty;498f1419 -> ../../php/Smarty
lrwxrwxrwx 1 root root   16 2009-02-08 11:05 smarty;498f1ee0 -> ../../php/Smarty
lrwxrwxrwx 1 root root   16 2009-02-08 18:23 smarty;498f8598 -> ../../php/Smarty

Those point to /usr/share/php/Smarty

-rw-r--r-- 1 root root 12742 2008-08-15 12:43 Config_File.class.php
-rw-r--r-- 1 root root  3562 2008-08-15 12:42 debug.tpl
drwxr-xr-x 2 root root  4096 2008-12-14 15:47 internals
drwxr-xr-x 2 root root  4096 2008-12-14 15:47 plugins
-rw-r--r-- 1 root root 63466 2008-08-15 12:42 Smarty.class.php
-rw-r--r-- 1 root root 92736 2008-11-03 10:23 Smarty_Compiler.class.php
-rw-r--r-- 1 root root 92618 2008-08-15 12:43 Smarty_Compiler.class.php.security~

So I suppose they can't be termed *dangling*, though I'm not sure what will happen to them on update.  Apparently even 
though yum called the update complete, rpm didn't actually flag it as complete, so it keeps trying to use the same update.

I made a mistake last time I checked by assuming that I was in the directory and checking a relative path instead of the 
absolute path.

HTH