Bugzilla Bug 32276

everytime i started revdep rebuild it starts to rebuild openoffice-bin(-1.1.0),
even if it was rebuild by revdep. 

revdep-output:
dd: warning: you do not have execution permission for
`/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/_tkinter.so'
  broken
/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/_tkinter.so
(requires libtk8.3.so libtcl8.3.so)
ldd: warning: you do not have execution permission for
`/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/bsddb.so'
  broken
/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/bsddb.so
(requires libdb-3.1.so)
ldd: warning: you do not have execution permission for
`/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/mpz.so'        
  broken
/opt/OpenOffice.org1.1.0/program/python-core-2.2.2/lib/lib-dynload/mpz.so
(requires libgmp.so.3)
 done.                          


Reproducible: Always
Steps to Reproduce:
1.
2.
3.

This is a broken dependency issue - I have the same problem. Also, the execute
bit should be set on these three files.

I don't know what the libraries that this depends on are, but we could do
with finding out...

Revdep rebuild searches it hardly everywhere. And tcl/tk-8.3 is not in unstable
profile for about than half year.

There are only two chances:

1) Library is provided in special way in normal binary (Java does it, bu
I do not beleive it is the case).

2) Those libraries are really broken. In this case openoffice-bin ebuild
is broken. I gues it is.

Solutions:

a) new updated binary package
or
b) install old tcl/tk to /opt/OpenOffice.org1.1.0
or
c) these libraries are probably not essential (tk support in built in python)
=> remove them, if not needed.

The missing libraries belong to:

=dev-lang/tcl-8.3*
=dev-lang/tk-8.3*
=sys-libs/db-3.1*
dev-libs/gmp

Unfortunately, there isn't a db-3.1* in portage any more. I've hacked together
a db-3.1.17 ebuild, although this clearly is NOT an ideal solution, as many
people will have db-3.2.9-r9 or db-3.2.9-r10 installed instead.

I will attach an ebuild for app-office/openoffice-bin-1.1.0 as well as one
for sys-libs/db-3.1.17. The openoffice-bin ebuild contains fixes for the
broken dependencies and permissions. The db-3.1.17 ebuild is required, or
the openoffice-bin ebuild is effectively useless.

Note that everything compiles and works fine here - I've only tested this,
however, on one machine. You'll need to rebuild the digest for sys-libs/db-3.1.17
too. If anyone has any problems with this, please reply here.

Created an attachment (id=20358) [details]
Updated ebuild for openoffice-bin-1.1.0

Created an attachment (id=20359) [details]
Ebuild for db-3.1.17

This ebuild is necessary for the openoffice-bin libdb-3.1.so dependency fix.

Oh, I should also point out that in the updated openoffice-bin ebuild, I've
also added the fix described in bug #32492 for the sed script.

Any news on this one? It is installing a broken package into the stable profile
here, so this should probably be fixed as a matter of some serious urgency...

*Bump*

Is the problem with this fix the fact that it requires an ebuild for an outdated (if very stable) package to be shoved into portage in the stable profile?

Really, though, this package is by no means stable for ANY arch when there are broken dependencies, as this breaks revdep-rebuild quite obviously.

Any news?

openoffice-bin provides it's own libraries for many things, including those
mentioned. In any case rebuilding it is pointless as it is a binary package.

It doesn't provide its own libraries for tcl, tk, db and gmp - otherwise,
revdep-rebuild wouldn't be trying to update them would it?

There is nothing wrong with this ebuild, as far as I can see - whilst things
are obviously broken in the one currently in portage.

What exactly are the objections to this updated ebuild?

openoffice-bin provides it's own version of db, building db-3.1.17 is not
necessary, if anything this is a bug (or missing feature) in revdep-rebuild. So
either we close this or hand it over to the Portage team

Weird. Are you absolutely sure about that? What is it that revdep-rebuild does
that it shouldn't?

Basically it is caused by revdep-rebuild not knowing that openoffice uses it's
own db. This is basically caused by the nature of the revdep-rebuild tool.
Except real reverse dependency and rebuild support in portage there is probably
not much that can be done against this except maybe adding some rule to
revdep-rebuild to tell it openoffice-bin does not need to be rebuild (pointless
anyway with binary packages)

*** Bug 42440 has been marked as a duplicate of this bug. ***

*** Bug 48389 has been marked as a duplicate of this bug. ***

For what it's worth, I'm working on a new, from-scratch revdep-rebuild that
should eliminate the problems above.

I have a similar problem on my machine: revdep-rebuild rebuilds "opera"
everytime I run it.

*** Bug 61189 has been marked as a duplicate of this bug. ***

Feel free to update LD_LIBRARY_MASK in revdep-rebuild for your needs. I am not
any longer actively maintaining it.

Is this only a problem with revdep-rebuild, or is there also a problem with
openoffice-bin-1.1.3 ?

revdep-rebuild complains about three missing libraries, two are available in
other versions, but one (libgmp.so.3) is missing alltogether.  Does
openoffice-bin lack a dependency for the latter, or does it just provide the
files somewhere else?  I have not noticed anything wrong with openoffice, but
then this is a new machine and I have hardly used it yet.

/Jakob

No, it's only a revdep rebuild error. It doesn't know that openoffice-bin is
binary, and also uses it's own libraries. Openoffice has no problems, just be
carefull with revdep-rebuild as it is not 100% correct.

*** Bug 77821 has been marked as a duplicate of this bug. ***

*** Bug 89599 has been marked as a duplicate of this bug. ***

FYI,

this is now happening with openoffice-bin-1.9.128:

  broken /usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/_bsddb.so
(requires  libdb-3.1.so)
  broken /usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/bz2.so
(requires  libbz2.so.0)
  broken /usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/mpz.so
(requires  libgmp.so.3)
  broken
/usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/_tkinter.so
(requires  libBLT24.so libtcl8.3.so libtk8.3.so)
 done.
  (/root/.revdep-rebuild.3_rebuild)

Does anyone know if there is any intent to fix revdep-rebuilds behavior in
regards to binaries like this? This bug is almost two years old.

It is fixed in gentoolkit-0.2.1_pre7, although with the most recent
openoffice-bin, you will need to add /usr/lib/openoffice to SEARCH_DIRS_MASK

@Paul: Could you please add /usr/lib/openoffice to the default SEARCH_DIRS_MASK
this is going to be the new default install dir for OOo 2.0

Is /usr/lib/openoffice going to be used only by openoffice-bin? If the
openoffice ebuild also uses that directory, then it isn't a good idea to have
revdep-rebuild mask the directory by default for everybody.

/usr/lib/openoffice is going to be used by all OOo-ebuilds, true that this is a
little bit of a problem. On the other hand, now both source and -bin use
/opt/OpenOffice.org so this is the same situation. Don't know how to solve this,
cause using different install dirs for -bin and source is not an option, as this
would break the user install and complicate the switch between both versions

I am not much of Gentoo Developer, but I am fairly active at sending bugs and
prodding here and there, occasionally doing my own ebuild. If I say nonsense,
please disregard. Maybe a REVDEP_IGNORE=true (or maybe
REVDEP_IGNORE="/opt/OpenOffice.org", also allowing multiple dirs and even
specific files, for maximum flexibility) flag could be added to the bin ebuild.
When revdep-rebuild runs, it will find the file, then look for all possible
providers, excluding the REVDEP_IGNORE=true ebuilds. If no ebuilds who produce
the file are found, it will do nothing. revdep-rebuild would be changed to look
for this flag, as well as each ebuild.

Created an attachment (id=69219) [details]
99revdep-rebuild

Starting with the next release of gentoolkit.  I will be reading variables from
files in /etc/revdep-rebuild/.	If an ebuild author wants to adjust the
behavior of revdep-rebuild, place a file in that directory.  I am attaching the
file that I will be using to set the defaults for revdep-rebuild.

I think adding a file would be a good solution. One question. Will these files
be accumulating all values mentioned? (Should
SEARCH_DIRS_MASK="$SEARCH_DIRS_MASK:/usr/lib/openoffice" be used?

The variables are accumulated in the following order:
* Environment
* /etc/make.conf
* /etc/revdep-rebuild/*

*** Bug 110261 has been marked as a duplicate of this bug. ***

I have released gentoolkit-0.2.1_pre9 which supports the placing of a
environment file for revdep-rebuild in /etc/revdep-rebuild.  On my system I have
the file /etc/revdep-rebuild/10openoffice-bin which contains
SEARCH_DIRS_MASK="/usr/lib/openoffice"

@Paul: Great!

So can we close that bug now? ;)

I don't want to actually close the bug until gentoolkit-0.2.1 goes stable since
experience has shown me that people will keep opening bugs about it.  Feel free
to remove yourself from the CC list.

I had the same problem, so I've created a patch for revdep-rebuild to exclude
bin packages from /root/.revdep-rebuild.4_ebuilds. It assumes only binary
packages end with -bin. It's contents is below. hope it's of use.

#----BEGIN REVDEP-REBUILD PATCH----
--- revdep-rebuild      2005-10-19 10:55:29.000000000 +0000
+++ /usr/bin/revdep-rebuild     2005-11-06 23:49:27.000000000 +0000
@@ -257,7 +257,7 @@
                        echo -n > $LLIST.4_ebuilds
                fi
        fi
-
+       grep -- -bin$ < $LLIST.4_ebuilds > $LLIST.4_ebuilds
        RAW_REBUILD_LIST="$(cat $LLIST.4_ebuilds | sed s/^/=/ | tr '\n' ' ')"
 fi

#----BEGIN REVDEP-REBUILD PATCH----

*** Bug 87829 has been marked as a duplicate of this bug. ***

Definitely /etc/revdep-rebuild/10openoffice-bin should be created by the ebuild
of openoffice-bin (and removed at unmerge). Working fine here after manual 
addition.

(In reply to comment #35)
> I have released gentoolkit-0.2.1_pre9 which supports the placing of a
> environment file for revdep-rebuild in /etc/revdep-rebuild.  On my system I have
> the file /etc/revdep-rebuild/10openoffice-bin which contains
> SEARCH_DIRS_MASK="/usr/lib/openoffice"
> 

A late reply, but: If someone changes from openoffice-bin to openoffice, this
would result in openoffice not being checked anymore as that file won't get
removed due to the config-file protections, right?

That is correct.  I'll update gentoolkit to CONFIG_PROTECT_MASK
/etc/revdep-rebuild/ in next releases.

For now, the only thing that I can think of to help is to put an einfo at the
end of the unmerge of openoffice-bin to remove the file.

(In reply to comment #41)
> (In reply to comment #35)
> > I have released gentoolkit-0.2.1_pre9 which supports the placing of a
> > environment file for revdep-rebuild in /etc/revdep-rebuild.  On my system I have
> > the file /etc/revdep-rebuild/10openoffice-bin which contains
> > SEARCH_DIRS_MASK="/usr/lib/openoffice"
> > 
> 
> A late reply, but: If someone changes from openoffice-bin to openoffice, this
> would result in openoffice not being checked anymore as that file won't get
> removed due to the config-file protections, right?
> 

It works like a charm, however, for amd64 it's
SEARCH_DIRS_MASK="/usr/lib32/openoffice"

*** Bug 128067 has been marked as a duplicate of this bug. ***

*** Bug 131620 has been marked as a duplicate of this bug. ***

(In reply to comment #42)
> That is correct.  I'll update gentoolkit to CONFIG_PROTECT_MASK
> /etc/revdep-rebuild/ in next releases.
> 

Any news on this, Paul? 

(In reply to comment #46)
> (In reply to comment #42)
> > That is correct.  I'll update gentoolkit to CONFIG_PROTECT_MASK
> > /etc/revdep-rebuild/ in next releases.
> > 
> 
> Any news on this, Paul? 
> 

Well: app-portage/gentoolkit-0.2.2_rc1

# emerge --info | grep CONFIG_PROTECT_MASK
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo
/etc/env.d"

So... what's holding this back?

(In reply to comment #47)
> So... what's holding this back?

Me not knowing about this? ;)

I've added this now to the ebuild for 2.0.3_rc4, masses will get it with the
release of 2.0.3.

So finally closing this :))))))))))))

It is in >=gentoolkit-0.2.2_pre3.  Since portage-2.1 is in the process of going
stable, I am getting ready to release gentoolkit-0.2.2 for stable as well.