After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 462155 - don't install breakpad libraries
don't install breakpad libraries
Status: RESOLVED FIXED
Product: bug-buddy
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Bug-buddy Maintainers
Bug-buddy Maintainers
: 462190 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-07-31 14:55 UTC by Matthias Clasen
Modified: 2007-09-04 17:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Clasen 2007-07-31 14:55:38 UTC
I think bug-buddy should just depend on google-breakpad. 
Since there has not been a google-breakpad release yet, bug-buddy needs to 
include breakpad for now, but it should not install libbreakpad as a public library. Either put it in a private place, or link it statically.
Comment 1 Fernando Herrera 2007-07-31 16:19:46 UTC
*** Bug 462190 has been marked as a duplicate of this bug. ***
Comment 2 Fernando Herrera 2007-07-31 16:23:16 UTC

Yeah, sorry guys about this. I planned to install a local copy of the library, something like /usr/lib/bug-buddy/libbreakpad.so, but I was in a hurry to release a tarball for GNOME release today.

Loïc, the rationale of using a local copy is that there is not release at all of google-breakpad yet. The plan is to use an upstream package as soon as it is released/included in distros. Is this ok for debian?

Comment 3 Loïc Minier 2007-07-31 16:41:51 UTC
(In reply to comment #2)
> Yeah, sorry guys about this. I planned to install a local copy of the library,
> something like /usr/lib/bug-buddy/libbreakpad.so, but I was in a hurry to
> release a tarball for GNOME release today.
> 
> Loïc, the rationale of using a local copy is that there is not release at all
> of google-breakpad yet. The plan is to use an upstream package as soon as it is
> released/included in distros. Is this ok for debian?


I suppose Debian could live with this; but I understood there were also some changes in the breakpad code base?

Alternatively, do you think a SVN snapshot would be enough?
Comment 4 Fernando Herrera 2007-07-31 16:51:35 UTC
only changes with upstream is removal of testdata (for saving space on the tarball) and autofoo magic to be able to distcheck (srcdir != buildir)
Comment 5 Matthias Clasen 2007-07-31 17:26:46 UTC
/usr/lib/bug-buddy/libbreakpad.so will work fine for Fedora.
Comment 6 Matthias Clasen 2007-09-03 15:55:24 UTC
Any update on this ? 
2.19.91 still wants to install /usr/lib/libbreakpad.so, it seems
Comment 7 Fernando Herrera 2007-09-03 16:19:51 UTC
next on my TODO list after fixing the distcheck on platform that doesn't compile google-breakpad.

a question for packagers: How can we handle co-existence of x86 and x86_64 gtk+ programs in the same machine? installing .i386 and .x86_64 packages on x86_64?
Comment 8 Fernando Herrera 2007-09-03 17:08:46 UTC
ok. fixed the library installation problem:

2007-09-03  Fernando Herrera  <fherrera@onirica.com>

        * google-breakpad/Makefile.am: install breapad library under
        $prefix/lib/bug-buddy dir because it's private to our instalation
        (until google-breakpad is properly released and we can depend on it)


I'm still installing $prefix/bin/minidump_dump and $prefix/bin/minidump_stackwalk
Probably a proper google-breakpad package includes these, so I don't know what to do:
a) Remove them from the bug-buddy/google-breakpad installation
b) Install them with some other name (as they could be useful for some developers)
Comment 9 Matthias Clasen 2007-09-04 17:08:13 UTC
How about --with-included-breakpad / --with-system-breakpad or somesuch ?