On 27/02/11 20:40, Xavier Chantry wrote:

On Sun, Feb 27, 2011 at 1:37 AM, Allan McRae wrote:

...

I just noticed this:

...

pacman -Qk | grep "^warning" warning: filesystem: /opt/ (No such file or directory) warning: hal: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hal-info: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hicolor-icon-theme: /usr/share/icons/hicolor/256x256/apps/ (No such file or directory) warning: network-manager-applet: /etc/gconf/schemas/ (No such file or directory)

All these directories are empty in their package. They appear to have been removed when I uninstalled a different package that had files in that directory.

Maybe we need some more checking before removing an empty directory.

Allan

http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/009008.html https://bugs.archlinux.org/task/15668 https://bugs.archlinux.org/task/11263

I had a fair suspicion this had been discussed before... I just did a "wtf?" when I saw /opt had disappeared. I'm going to create a pactest for this. Allan

On 27/02/11 21:01, Xavier Chantry wrote:

On Sun, Feb 27, 2011 at 11:53 AM, Allan McRae wrote:

...

I had a fair suspicion this had been discussed before... I just did a "wtf?" when I saw /opt had disappeared.

I'm going to create a pactest for this.

If we believe the performance hit to fix this problem is not worth it, why not consider these packaging problems, and have all these packages install a .keep file ?

How much of a performance hit would there really be? If I have this right in my head (big assumption), the file-lists for all packages are read in in one go. So all that we would have to do is loop over them checking for the empty directory before we add it to the removal list. Should be a minimal impact.... maybe... I suppose the best way is to make a patch and see! Allan

On 27/02/11 21:48, Xavier Chantry wrote:

On Sun, Feb 27, 2011 at 12:40 PM, Allan McRae wrote:

...

How much of a performance hit would there really be? If I have this right in my head (big assumption), the file-lists for all packages are read in in one go. So all that we would have to do is loop over them checking for the empty directory before we add it to the removal list. Should be a minimal impact.... maybe...

I suppose the best way is to make a patch and see!

AFAIK the file lists currently do not need to be loaded with -R, so the impact would be loading them more than the checking itself. Then again, we have that cost for all -S operation already, so why not make -R as bad ? :)

strace tells me that I was wrong and you are right. So that is big overhead...

Anyway we will keep having problems until we have a single file for the local db as well.

Yes, we will. I might attempt to a gathering of the contenders for improving this post 3.5. Allan

On Sun, Feb 27, 2011 at 4:53 AM, Allan McRae wrote:

On 27/02/11 20:40, Xavier Chantry wrote:

...

On Sun, Feb 27, 2011 at 1:37 AM, Allan McRae  wrote:

...

I just noticed this:

...

pacman -Qk | grep "^warning"

warning: filesystem: /opt/ (No such file or directory) warning: hal: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hal-info: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hicolor-icon-theme: /usr/share/icons/hicolor/256x256/apps/ (No such file or directory) warning: network-manager-applet: /etc/gconf/schemas/ (No such file or directory)

All these directories are empty in their package.  They appear to have been removed when I uninstalled a different package that had files in that directory.

Maybe we need some more checking before removing an empty directory.

Allan

http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/009008.html https://bugs.archlinux.org/task/15668 https://bugs.archlinux.org/task/11263

I had a fair suspicion this had been discussed before...  I just did a "wtf?" when I saw /opt had disappeared.

I'm going to create a pactest for this.

Agreed- I think we've just tried to ignore this in the past because we knew the solution would require a lot more overhead, but it probably makes sense to add a test and re-open FS#11263 for this. -Dan