I'm seeing the same thing. I sent this to maemo-devel--I'm including it here
for convenience:


I built a simple package that is a plugin for pidgin called pidgin-otr. When I
maemo-optify-deb it, it creates a symlink to itself.


* I did the standard easy optification:
echo auto > debian/optify


* The package built/installed fine in scratchbox:
[sbox-FREMANTLE_ARMEL: ~] > ls -l /usr/lib/pidgin/pidgin-otr.so

-rw-r--r--  1 jebba jebba 81072 Jan  5 14:09 /usr/lib/pidgin/pidgin-otr.so


* I removed package.

* I then optified:
[sbox-FREMANTLE_ARMEL: ~] > maemo-optify-deb pidgin-otr_3.2.0-7_armel.deb

pidgin-otr: optified 10 entries, saving about 185 kB.
dpkg-deb: building package `pidgin-otr' in `pidgin-otr_3.2.0-7_armel.deb'.


* I then installed optified package.


[sbox-FREMANTLE_ARMEL: ~] > ls -l /usr/lib/pidgin/pidgin-otr.so

lrwxrwxrwx  1 jebba jebba 39 Jan  5 14:55 /usr/lib/pidgin/pidgin-otr.so ->
/opt/maemo/usr/lib/pidgin/pidgin-otr.so


But here is where the problem came in:

[sbox-FREMANTLE_ARMEL: ~] > ls -l /opt/maemo/usr/lib/pidgin/pidgin-otr.so
lrwxrwxrwx  1 jebba jebba 39 Jan  5 14:55
/opt/maemo/usr/lib/pidgin/pidgin-otr.so ->
/opt/maemo/usr/lib/pidgin/pidgin-otr.so


The optified file is symlinking to itself, thus breaking the package.

I'll leave this directory here for awhile if someone wants to check it out. It
is my live scratchbox:
http://www.freemoe.org/users/jebba/scratchbox/pidgin-otr-OPTIFY_PROB/

The two different .debs for comparison are here:
pidgin-otr_3.2.0-7_armel.deb-NOOPTIFY
pidgin-otr_3.2.0-7_armel.deb-OPTIFY

I´m having the same problem with 'conboy' as main package and 'conboy-midgard'
as plugin package.

I think I see what's happening:

1. the main package is installed first and symlinks /usr/lib/foo to
/opt/maemo/usr/lib/foo
2. the derivative package installation first extracts the real bar.so file to
/opt/maemo/usr/lib/foo/bar.so
3. then it extracts the /usr/lib/foo/bar.so symlink, follows the /usr/lib/foo
symlink in the process and thus overwrites the original with a recursive link.

If the optification links were extracted first there would be no problem, but
unfortunately it looks like they always end up at the end of data.tar.gz. 
Fixing this would require either hacking dpkg-dev or repackaging manually, both
too ugly to consider IMHO.

Perhaps maemo-optify should leave directories alone and only optify regular
files?

(@Bryan: thanks for working on claws-mail btw, much appreciated - and feel free
to change the Maintainer field in some future update :-) )

I have problems with scopa-cards-extra, too. Where are a second package build
formt he same package source seems to have problems with symlinks generated by
optify.

Comment 5 Marius Vollmer 2010-02-01 11:22:03 UTC

I still have to analyze this more carefully, but right I think it might work to
change maemo-optify so that it doesn't ever put new symlinks into the package. 
Directories will be symlinked in preinst (and keep their location inside the
package), files will be moved inside the package and the symlink is added in
postinst.

When creating the symlink in preinst or postinst, the scripts will be careful
not to mess things up, by, for example, creating symlink loops.

Does this sound like it could solve this problem?

Comment 6 Marius Vollmer 2010-02-04 19:15:55 UTC

Alright, there is maemo-optify 0.3 now, with a totally new and raw optification
strategy.

    http://maemo.gitorious.org/maemo-af/maemo-optify/

I haven't uploaded this yet to the buildbot, though, since I would like to get
some more eyes on this first.  So, anybody?

The new strategy is explained in maemo-optify itself and implemented in the
optify_dir.sh, optify_file.sh and optify_remove.sh files:

    http://maemo.gitorious.org/maemo-af/maemo-optify/trees/master

Now, with this (theoretically) more robust optification, I am tempted to change
the heuristic to be less careful about directories.  What about optifiying
every directory directly below /usr/share that has more than 10 entries, say?

Version 0.3 of maemo-optify fixed the problems I described with pidgin-otr
above.

I have also run it on all the .debs in my Etch rebuild. The optified versions
are here:
http://obra.freemoe.org/freemoe-etch/

Non-optified here:
http://obra.freemoe.org/freemoe-etch-NON_OPTIFIED/

And a couple logfiles of the processing:
http://obra.freemoe.org/freemoe-etch/maemo-optify.err
http://obra.freemoe.org/freemoe-etch/maemo-optify.log

OK, this maemo-optify 0.3 actually doesn't work:

# Install some small text application:
$ apt-get install bwbar

# See that it *doesn't* install anything to /usr/sbin (no symlinks, nothing).
$ dpkg -L bwbar
/.             
/usr
/usr/sbin
/usr/share
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/bwbar.8.gz
/usr/share/doc                
/usr/share/doc/bwbar
/usr/share/doc/bwbar/copyright
/usr/share/doc/bwbar/changelog.Debian.gz
/usr/share/doc/bwbar/README.Debian      
/usr/share/doc/bwbar/README       
/opt                       
/opt/maemo
/opt/maemo/usr
/opt/maemo/usr/sbin
/opt/maemo/usr/sbin/bwbar
/etc                     
/etc/init.d
/etc/init.d/bwbar
/etc/default     
/etc/default/bwbar


# Try to remove it.
$ sudo apt-get remove bwbar            
Reading package lists... Done           
Building dependency tree                
Reading state information... Done       
The following packages will be REMOVED: 
  bwbar                                 
0 upgraded, 0 newly installed, 1 to remove and 62 not upgraded.
After this operation, 111kB disk space will be freed.          
Do you want to continue [Y/n]?                                 
(Reading database ... 31127 files and directories currently installed.)
Removing bwbar ...                                                     
rm: cannot remove '/usr/sbin/bwbar': No such file or directory         
dpkg: error processing bwbar (--remove):                               
 subprocess post-removal script returned error exit status 1           
Errors were encountered while processing:                              
 bwbar                                                                 
E: Sub-process /usr/bin/dpkg returned an error code (1)
# Doh! Can't remove it!


# And it's still listed as installed.
$ dpkg -l bwbar
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                                                Version                
                   Description
+++-===================================================-==========================================-=============================================================
pH  bwbar                                               1.2.3-1                
                   generates text and graphical readout of current bandwidth
use



In sum, nothing gets installed to /usr/sbin and now the package can't be
removed.

Comment 9 Marius Vollmer 2010-02-08 09:29:53 UTC

(In reply to comment #8)

> In sum, nothing gets installed to /usr/sbin and now the package can't be
> removed.

Thanks for the report.  I'll check this out.

What is supposed to happen is that the postinst script will create the
/usr/sbin/bwbar symlink, and the postrm will remove it.  The postrm should
probably not fail when the link isn't there, just so that people don't get
stuck with a broken package like it happened here.

Could you try one or two other packages and see whether they fail in the same
way?

I have also pushed a untested change to optify_remove.sh that turns the error
into a warning.  Would be great if you could try it.

(In reply to comment #9)
> Could you try one or two other packages and see whether they fail in the same
> way?

Another user reported the same thing, but with the git package:
# dpkg -r git

(Reading database ... 31715 files and directories currently installed.)
Removing git ...
install-info(/usr/share/info/git.info.gz): no file /usr/share/info/dir,
retrieving backup file /var/backups/infodir.bak.
rm: cannot remove '/usr/bin/gitfm': No such file or directory
rm: cannot remove '/usr/bin/gitview': No such file or directory
rm: cannot remove '/usr/bin/gitwhich': No such file or directory
...etc

> I have also pushed a untested change to optify_remove.sh that turns the error
> into a warning.  Would be great if you could try it.

Will do.

With the latest maemo-optify, it's not putting a file in /usr/sbin.

~ $ dpkg -L bwbar
/.
/usr
/usr/sbin
/usr/share
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/bwbar.8.gz
/usr/share/doc
/usr/share/doc/bwbar
/usr/share/doc/bwbar/copyright
/usr/share/doc/bwbar/changelog.Debian.gz
/usr/share/doc/bwbar/README.Debian
/usr/share/doc/bwbar/README
/opt
/opt/maemo
/opt/maemo/usr
/opt/maemo/usr/sbin
/opt/maemo/usr/sbin/bwbar
/etc
/etc/init.d
/etc/init.d/bwbar
/etc/default
/etc/default/bwbar

~ $ ls -l /usr/sbin/bwbar
ls: /usr/sbin/bwbar: No such file or directory


But it can be removed cleanly:

Removing bwbar ...
Optify: /usr/sbin/bwbar is not a symlink, not removing it.


The new optified repo is up at:
http://obra.freemoe.org/freemoe-etch/

(In reply to comment #9)
> (In reply to comment #8)
> 
> > In sum, nothing gets installed to /usr/sbin and now the package can't be
> > removed.
> 
> Thanks for the report.  I'll check this out.
> 
> What is supposed to happen is that the postinst script will create the
> /usr/sbin/bwbar symlink, and the postrm will remove it.  The postrm should
> probably not fail when the link isn't there, just so that people don't get
> stuck with a broken package like it happened here.
> 
> Could you try one or two other packages and see whether they fail in the same
> way?
> 
> I have also pushed a untested change to optify_remove.sh that turns the error
> into a warning.  Would be great if you could try it.

That seems to have worked, since jebba's new git package has a prerm script
that works (I can use apt-install git to use the new .deb's prerm script to
remove the extant git .deb files).

However the installation fails in two ways:

1) /usr/bin symlinks are not made for optified files (jebba's mentioned how in
#c10)
2) /usr/share/info/git.info.gz file is not present (it's been moved to
/opt/maemo/... in the .deb, and it's not part of the optify function calls in
the git.preinst script), causing the git.postinst script (which expects
/usr/share/info/git.info.gz to exist) to fail:

cdc1:~# dpkg -i /var/cache/apt/archives/git_4.3.20-10_armel.deb 
Selecting previously deselected package git.
(Reading database ... 31783 files and directories currently installed.)
Unpacking git (from .../git_4.3.20-10_armel.deb) ...
Optifying /usr/share/git
Optifying /usr/share/doc/git
Setting up git (4.3.20-10) ...
sh: cannot open /usr/share/info/git.info.gz: no such file
install-info(/usr/share/info/git.info.gz): 
dpkg: error processing git (--install):
 subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 git
cdc1:~#

I suspect that /usr/share files may not be properly handled by the optification
process.

The latest git breaks some python packages too, perhaps related to /usr/share
as mentioned above.

...
Unpacking bittornado (from .../bittornado_0.3.17-1_all.deb) ...
Optifying /usr/share/doc/bittornado
Setting up bittornado (0.3.17-1) ...
Usage: update-python-modules [-v] [-c] package_directory [...]
       update-python-modules [-v] [-c] package.dirs [...]
       update-python-modules [-v] [-a|-f|-p]

update-python-modules: error: bittornado.public is not a recognized
python-support module.
...

Because there is no symlink for this file:
$ dpkg -L bittornado|grep public
/opt/maemo/usr/share/python-support/bittornado.public

Here's one using /usr/share/games:

Unpacking bugsquish (from .../bugsquish_0.0.6-5_armel.deb) ...
Optifying /usr/share/games/bugsquish
ln: /usr/share/games/bugsquish: No such file or directory
Optifying /usr/share/doc/bugsquish
Setting up bugsquish (0.0.6-5) ...

In this case most of the app didn't get optified:

$ du -sh /usr/share/games/bugsquish/
964.0k  /usr/share/games/bugsquish

Only the main binary got moved:

~ $ ls -l /opt/maemo/usr/games/bugsquish
-rwxr-xr-x    1 1000     1000        22524 Jan 27 07:10
/opt/maemo/usr/games/bugsquish

I'm not so sure about the idea of symlinking with the .postinst. This breaks
things like:

dpkg -S /usr/bin/foo

if foo was just symlinked there.

You have files in /usr that aren't directly tracked by the packaging system.
This also allows them to be overwritten in corner cases. It seems the most
prudent way would be to have the .deb know about all the files it (and it's
.postinsts) installs on a system.

Comment 16 Marius Vollmer 2010-02-11 14:56:13 UTC

(In reply to comment #13)
> The latest git breaks some python packages too, perhaps related to /usr/share
> as mentioned above.

Yes.  The problem is likely the timing of optification: currently, postinst
optification is done
as the last thing, which is clearly too late.

So I am moving file optification to the preinst as well.  This will create
dangling symlinks for a short while until the package is actually unpacked, but
that should not cause trouble.

Also, preinst optification will be done as the first thing, before the normal
preinst actions of the package.

> Because there is no symlink for this file:
> $ dpkg -L bittornado|grep public
> /opt/maemo/usr/share/python-support/bittornado.public

Yes.  It would have been made by postinst, but too late. 

The problem with bwbar was that its postinst contains an explicit "exit 0" and
thus the optification is never reached.

I'll make that change and come back here when it is done.

Comment 17 Marius Vollmer 2010-02-11 16:27:23 UTC

(In reply to comment #16)

> I'll make that change and come back here when it is done.

Ok, I have pushed it:

http://maemo.gitorious.org/maemo-af/maemo-optify/commit/8c655c94445c9904329fbb8aed88337fb14c099a

Please test.

Ok, I have re-processed the repo if you want to take a look at any of the
.debs. http://obra.freemoe.org/freemoe-etch-OPTIFIED-0.3.1pre2/

I just tried to optify Conboy + Plug-ins again, and I still the the recursive
sym link. The package is optified via /debian/optify (auto).

http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/conboy/0.6.3.4/

I guess the new version of maemo-optify is not yet used by the builder, or is
it?

Tried again. Still no luck. Marius, are you still working on it? Or is the
problem, that the autobuilder is still using an old version of maemo-optify?

http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/conboy/0.6.3.9-2/

Is there anything I can do to help?

(In reply to comment #20)
> Is there anything I can do to help?

Have Patience(tm)!



 ;)

Well, I'm sure glad I put all the work into this that I did.

Thanks Jeff - your time is appreciated.