Bug 718404

Summary: conflicts installing glib2-devel.i686 along-side glib2-devel.x86_64
Product: [Fedora] Fedora Reporter: Bill Gianopoulos <wgianopoulos>
Component: glib2Assignee: Matthias Clasen <mclasen>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: aardvark, alevy, alexis.lameire, bgilbert, bugzilla.redhat.com, dmalcolm, dwayne.fontenot, flu, generalpenguin89, hongjiu.lu, igor, jistone, kinetik, knoel, markhamj, mathstuf, maurizio.antillon, mclasen, nphilipp, phil, rstrode, rth, shawn.p.huang, simon.lewis, spetreolle, walters
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 846717 (view as bug list) Environment:
Last Closed: 2013-08-01 14:44:15 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 846717    
Attachments:
Description Flags
patch to solve the bug
walters: review-
rebased fix
walters: review-
2.32.0-2 based glib2.spec patch
walters: review-
2.32.0 based, replaced # % with # to avoid macro in comment warnings from rpmlint
walters: review-
Workaround shell script
none
conflicting systemtap tapset fix none

Description Bill Gianopoulos 2011-07-02 09:47:37 EDT
Description of problem:

The version of glib2-devel that ships with fedora 15 adds files that install in /usr/share/dlib-2.0/gdb.  This results in conflicts if you try to install both the 32-bit and 64-bit versions of this package.  This essentially makes it no longer possible to develop 32-bit software under a 64-bit version of fedora.  This has always worked in previous versions.


Version-Release number of selected component (if applicable): glib2-devel-2.28.8-1.fc15.i686


How reproducible: Always


Steps to Reproduce:
1. yum install glib2-devel.x86_64
2. yum install glib2-devel.i686
3.
  
Actual results: Conflicts in various files in /usr/share/glib-2.0/gdb resulting in failure of the installation.


Expected results: Expect both packages to be able to be installed.


Additional info: This impacts my ability to do Mozilla software development.
Comment 1 Lameire Alexis 2011-07-14 11:24:20 EDT
i confirm this bug, you must think to merge this new file into a separete package
Comment 2 Lameire Alexis 2011-07-15 08:16:54 EDT
Created attachment 513368 [details]
patch to solve the bug

i have add a patch to solve the bug, if the maintener would like add it and rebuild the package.
Comment 3 Bill Gianopoulos 2011-11-12 15:38:59 EST
Silly me just installed fedora 16 and assumed this would have been fixed by now.  But, alas the issue still exists.
Comment 4 Avi Kivity 2011-12-05 08:21:05 EST
Issue exists for me too.
Comment 5 Patrick MacArthur 2012-02-11 14:31:08 EST
I have also experienced this issue on Fedora 16 x86_64.
Comment 6 Matthias Clasen 2012-02-16 11:30:15 EST
*** Bug 784269 has been marked as a duplicate of this bug. ***
Comment 7 Ben Boeckel 2012-03-19 23:02:15 EDT
Looking over the guidelines, there is nothing that states that -devel packages have to be multiarch compatible. I think this is likely an oversight. I would recommend opening a bug for the FPC[1] to add to the guidelines that -devel packages have to be parallel-installable with multiarch.

[1]https://fedorahosted.org/fpc/
Comment 8 Alon Levy 2012-03-21 08:07:45 EDT
*** Bug 757174 has been marked as a duplicate of this bug. ***
Comment 9 Alon Levy 2012-03-21 10:35:24 EDT
Created attachment 571730 [details]
rebased fix
Comment 10 Ben Boeckel 2012-03-21 12:14:37 EDT
(In reply to comment #9)
> Created attachment 571730 [details]
> rebased fix

Some spelling errors:

undependant -> independent
commun -> common

Also, the "#%" thing can make RPM unhappy; just changing the % to a # is usually done.
Comment 11 Alon Levy 2012-03-31 08:19:06 EDT
Created attachment 574199 [details]
2.32.0-2 based glib2.spec patch

Rebased on 2.32.0, corrected both spelling errors, added space between "#" and "%" which is just what the version before the patch had.

Alon
Comment 12 Alon Levy 2012-03-31 08:30:23 EDT
Created attachment 574201 [details]
2.32.0 based, replaced # % with # to avoid macro in comment warnings from rpmlint

Or use this version, it passes rpmlint with no warnings and errors using the suggestion the second before last comment.

(and the patch is correctly named, it's 2.32, not 2.33 - but that was just the patch name).

Alon
Comment 13 Alon Levy 2012-03-31 08:49:09 EDT
forget both comments, my bad - there are move changes then just bumping the version. Looks like a glib2-common would also be needed. Here is the list of conflicts:

glib2-devel conflicts that can go to glib2-common-devel
 /usr/include/*
 /usr/bin/glib-gettextize
 /usr/bin/glib-mkenums
 /usr/bin/gtester-report
  -> all three are perl/python/posix scripts.

glib2 conflicts (glib2-common?)
 /usr/share/man/man1/*
 /usr/share/locale/*
 /usr/share/doc/glib2-2.32.0/*
 /etc/bash_completion.d/*
Comment 14 Philippe Troin 2012-06-12 18:21:54 EDT
Still present in 2.32.3-1.fc17:

Transaction Check Error:
  file /usr/bin/gdbus-codegen from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
  file /usr/share/glib-2.0/gdb/glib.pyc from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
  file /usr/share/glib-2.0/gdb/glib.pyo from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
  file /usr/share/glib-2.0/gdb/gobject.pyc from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
  file /usr/share/glib-2.0/gdb/gobject.pyo from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
  file /usr/share/systemtap/tapset/glib.stp from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
  file /usr/share/systemtap/tapset/gobject.stp from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
Comment 15 markhamj 2012-07-07 10:28:40 EDT
Working on FC15.   Has a workaround / patch been identified for 2.6.43.8-1.fc15.x86_64?
Comment 16 Bill Gianopoulos 2012-07-07 13:25:16 EDT
Created attachment 596788 [details]
Workaround shell script

This it the workaround I am using.  Instead of installing glib2-devel.i686, I just run this script as root each time glib2-devel is updated.
Comment 17 Bill Gianopoulos 2012-07-07 15:53:20 EDT
Oh I should mention that in addition to the above script you also need to make sure you install glib2.i686 and elfutils-libelf.i686 which would normally be dependencies fo the glib2-devel.i686 package.
Comment 18 Bill Gianopoulos 2012-07-07 15:54:33 EDT
You should install those before running the workaround shell script.
Comment 19 Dwayne Fontenot 2012-07-23 12:36:55 EDT
Bill,

How does your script help with all the -devel packages which depend on glib-devel.i686 ?
Comment 20 Bill Gianopoulos 2012-07-23 16:04:46 EDT
(In reply to comment #19)
> Bill,
> 
> How does your script help with all the -devel packages which depend on
> glib-devel.i686 ?

Unfortunately it doesn't.

However, what it does do is permit to build 32-bit versions of Mozilla products, which was my original issue that prompted me to file this bug.
Comment 21 Fedora End Of Life 2012-08-07 13:12:13 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Nils Philippsen 2012-08-14 10:35:57 EDT
Reopening as this issue still exists on F-17.
Comment 23 Nils Philippsen 2012-08-14 10:36:30 EDT
*** Bug 846717 has been marked as a duplicate of this bug. ***
Comment 24 Nils Philippsen 2012-08-14 10:41:54 EDT
*** Bug 828448 has been marked as a duplicate of this bug. ***
Comment 25 Colin Walters 2012-08-14 11:08:09 EDT
One should use mock (or equivalent) to build 32 bit binares on a 64 bit host.

However, I'd review a patch if someone cared enough to rebase against rawhide/master.  Note that the -static subpackage is gone now.
Comment 26 Avi Kivity 2012-08-14 13:04:20 EDT
(In reply to comment #25)
> One should use mock (or equivalent) to build 32 bit binares on a 64 bit host.

In that case, we can drop *-devel.i686 on x86_64.  But I wish we wouldn't, this was a useful feature for me until this bug.
Comment 27 Nils Philippsen 2012-08-15 09:06:25 EDT
(In reply to comment #25)
> One should use mock (or equivalent) to build 32 bit binares on a 64 bit host.

One of the main reasons I use 32bit devel packages on 64bit hosts is to quickly build 32bit executables, e.g. to check architecture-dependent differences in the binaries, like when some types only overflow on 32bit, but not 64bit. It's pretty handy when dealing with security issues.

> However, I'd review a patch if someone cared enough to rebase against
> rawhide/master.  Note that the -static subpackage is gone now.

Sure. I want to compare the current sub-packages between 64bit and 32bit to ensure that I catch all conflicts.
Comment 28 Don Koch 2012-08-26 12:34:57 EDT
This also blocks inclusion of gstreamer support in wine.
Comment 29 Richard Henderson 2012-09-26 22:18:53 EDT
+1 to co-developing 32-bit and 64-bit binaries without actually having
to create a separate vm install, or whatever.  This used to work...
surely a simple matter of appropriate subpackaging?
Comment 30 Colin Walters 2012-09-27 09:16:24 EDT
(In reply to comment #29)
> +1 to co-developing 32-bit and 64-bit binaries without actually having
> to create a separate vm install, or whatever.  This used to work...
> surely a simple matter of appropriate subpackaging?

You don't need a separate virtual machine - mock creates relatively lightweight containers.
Comment 31 Bill Gianopoulos 2012-09-27 10:52:59 EDT
(In reply to comment #30)
> (In reply to comment #29)
> > +1 to co-developing 32-bit and 64-bit binaries without actually having
> > to create a separate vm install, or whatever.  This used to work...
> > surely a simple matter of appropriate subpackaging?
> 
> You don't need a separate virtual machine - mock creates relatively
> lightweight containers.

When I looked into this, it seemed lightweight as opposed to VM but seemed that I would need to install packages that I already need on the native OS in order to run 32-bit apps again under mock so that I was wasting a lot of disk space doing things that way.
Comment 32 Bill Gianopoulos 2012-09-27 10:54:14 EDT
BTW.  The way I have been doing 32-bit installs under 64-bit OS had worked at least since fedora version 6.
Comment 33 Ben Boeckel 2012-09-27 11:05:50 EDT
(In reply to comment #30)
> You don't need a separate virtual machine - mock creates relatively
> lightweight containers.

Unfortunately, mock is not the ideal development environment either for hacking on/debugging things.
Comment 34 Philippe Troin 2012-09-27 11:47:38 EDT
(In reply to comment #33)
> Unfortunately, mock is not the ideal development environment either for
> hacking on/debugging things.

Yes, ./configure CC='gcc -m32' is way easier than mock, VMs, or whatnot.
Fedora has mostly been very good with the 32/64 bit library coexistence, but there's always a few straggler packages that break, mostly for stupid things (did anyone say Doxygen?).
I always end up filing and refiling dozens of bugs every release :-/
Comment 35 Colin Walters 2012-09-27 13:08:26 EDT
(In reply to comment #34)

> I always end up filing and refiling dozens of bugs every release :-/

That's because multilib as it exists in Fedora/OpenSUSE/RHEL was *never designed* for this.  It was just a hack so you could *run* 32 bit binaries on a 64 bit host system; nothing to do with compiling.

On the other hand, Debian's multiarch is designed for this: http://wiki.debian.org/Multiarch
Comment 36 Bill Gianopoulos 2012-09-27 13:13:22 EDT
But the problem here is that there is a bunch of python crap having zero to do with the traditional lib-devel packages that is provided with both packages is the same in both packages , but is not marked a non-conflicting.  I mean really why are we arguing about his crap?
Comment 37 Bill Gianopoulos 2012-09-27 13:14:24 EDT
OH may not have been python i did not really check cause i don't remember but the part that conflicts really does not because it is identical in both packages.
Comment 38 Colin Walters 2012-09-27 13:16:54 EDT
Ok so there's two roots to this:

1) Python .py{c,o} files embed architecture-specific data, but we're installing them in %{datadir}
2) The systemtap tapsets encode the absolute path to the shared library, which is architecture-specific

Splitting off a noarch -devel-common is really a hack, because it doesn't solve that - in fact, whether or not the tapset will work will be a random function of whatever architecture the builder happened to be!
Comment 39 Colin Walters 2012-09-27 13:17:15 EDT
Comment on attachment 513368 [details]
patch to solve the bug

Breaks systemtap.
Comment 40 Colin Walters 2012-09-27 13:18:57 EDT
(In reply to comment #36)
> But the problem here is that there is a bunch of python crap having zero to
> do with the traditional lib-devel packages that is provided with both
> packages is the same in both packages , but is not marked a non-conflicting.
> I mean really why are we arguing about his crap?

We can relatively easily solve the Python bytecode conflict by simply deleting it, and in fact I will commit a patch to F18 to do this now.

Solving the systemtap one is not that easy.
Comment 41 Bill Gianopoulos 2012-09-27 13:54:00 EDT
(In reply to comment #35)
> (In reply to comment #34)
> 
> > I always end up filing and refiling dozens of bugs every release :-/
> 
> That's because multilib as it exists in Fedora/OpenSUSE/RHEL was *never
> designed* for this.  It was just a hack so you could *run* 32 bit binaries
> on a 64 bit host system; nothing to do with compiling.
> 
> On the other hand, Debian's multiarch is designed for this:
> http://wiki.debian.org/Multiarch

OK, SO you are saying that for my Mozilla developement activities I should switch form fedora to Debian?  Seems like an odd suggestion to be coming form someone with a redhat email address.
Comment 42 Bill Gianopoulos 2012-09-27 13:57:40 EDT
BTW this is why I am still doing my Mozilla development under fedora 14.  But if the answer is this will not be fixed and works under debian, I could easily just switch distro's.
Comment 43 Colin Walters 2012-09-27 14:56:24 EDT
(In reply to comment #41)

> OK, SO you are saying that for my Mozilla developement activities I should
> switch form fedora to Debian?  Seems like an odd suggestion to be coming
> form someone with a redhat email address.

I used to be a Debian developer and in fact, wrote the second most popular Debian build system (CDBS).  My highest loyalty is to Free Software, not a particular packaging format.

That said, you can't switch to the current release of Debian and have it work - multiarch is targeted for Wheezy in 2013 last I heard (http://lwn.net/Articles/482952/)

So, I do really want to help you use Fedora (or more ideally Red Hat Enterprise Linux) for the Mozilla build system. 

I'll pull the Systemtap people into this discussion and figure out how we can have multilib tapsets.
Comment 44 Colin Walters 2012-09-27 15:32:11 EDT
*** Bug 708442 has been marked as a duplicate of this bug. ***
Comment 45 Frank Ch. Eigler 2012-09-27 15:40:48 EDT
Several possible solutions to the systemtap part of the problem:

- use autoconf or whatnot to generate a arch/version-tagged set of .stp files (which would contain in them the arch/version-specific shared library names)
  e.g. for glib.stp, rename to x86-64-v2.0-glib.stp
  (Last I checked, hotspot does this.)

- use wildcards in the .stp files (so that their content is arch/version-invariant:
  e.g. for glib.stp:
- probe FOO = process("/lib64/libglib-2.0.so.0.3000.3").mark("quark__new")
+ probe FOO = process("/lib*/libglib*").mark("quark__new")
  (and/or /usr/lib*)

- nag us harder to implement http://sourceware.org/bugzilla/show_bug.cgi?id=10485
  which is a non-wildcard way of doing approx. the same thing
Comment 46 Colin Walters 2012-09-27 16:20:41 EDT
(In reply to comment #45)
> Several possible solutions to the systemtap part of the problem:
> 
> - use autoconf or whatnot to generate a arch/version-tagged set of .stp
> files (which would contain in them the arch/version-specific shared library
> names)
>   e.g. for glib.stp, rename to x86-64-v2.0-glib.stp
>   (Last I checked, hotspot does this.)

Testing a build with this now.
Comment 47 Ray Strode [halfline] 2012-09-27 17:12:32 EDT
fche, out of curiosity, do you if libdl dynamic string tokens work?  e.g., 

probe FOO = process("/$LIB/libglib-2.0.so.0.3000.3").mark("quark__new")

(not advocating it over the other possiblities, just curious)
Comment 48 Colin Walters 2012-09-27 20:15:27 EDT
Depends on upstream fix: https://bugzilla.gnome.org/show_bug.cgi?id=685012

We could probably backport this for Fedora 18 though.
Comment 49 Dave Malcolm 2012-09-28 16:14:29 EDT
(In reply to comment #38)
> 1) Python .py{c,o} files embed architecture-specific data, but we're
> installing them in %{datadir}
They're likely to only differ due to the timestamp embedded in the header, which is the mtime of the corresponding .py file.  If this is coming from the tarball, these ought to be the same on every arch you build for.  If you're touching the .py file during the build, you can fix the timestamp back by running:

  touch -r PATH_TO_SOME_SOURCE_FILE  PATH_TO.py

so that they have the timestamp from the tarball.
Comment 50 Colin Walters 2012-10-01 15:00:58 EDT
(In reply to comment #49)
> (In reply to comment #38)
> > 1) Python .py{c,o} files embed architecture-specific data, but we're
> > installing them in %{datadir}
> They're likely to only differ due to the timestamp embedded in the header,
> which is the mtime of the corresponding .py file. 

Hm, doesn't at least in some cases the generated bytecode differ depending on sizeof(long)?
Comment 51 Colin Walters 2012-10-01 18:46:33 EDT
(In reply to comment #49)
> If
> you're touching the .py file during the build, you can fix the timestamp
> back by running:
> 
>   touch -r PATH_TO_SOME_SOURCE_FILE  PATH_TO.py
> 
> so that they have the timestamp from the tarball.

Ok, so it turns out that using
make install DESTDIR=${RPM_BUILD_ROOT} INSTALL="install -p -c" 
fixes the .py{c,o} timestamps for everything except config.py, which is generated at build time.

I could hack this by resetting the timestamp to some known quantity (config.py.in time, 0, 42, ...), but it would seem cleaner to me to either:

1) Disable the timestamp in .py{c,o} files - e.g. somehow force Python to use 0
2) Not ship the .py{c,o} files
Comment 52 Colin Walters 2012-10-02 08:38:54 EDT
Pile of hacks, but: http://koji.fedoraproject.org/koji/taskinfo?taskID=4549425
Comment 53 Nils Philippsen 2012-10-10 11:55:50 EDT
(In reply to comment #52)
> Pile of hacks, but:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4549425

Works for me on F-18, thanks! And sorry for dropping this before I went on vacation (I mostly stumbled over the systemtap stuff and kind of gave up).

(In reply to comment #51)
> 2) Not ship the .py{c,o} files

It's desirable to have these packaged as otherwise python might want to (re)create them during runtime and if successful they wouldn't be cleaned up when the package is uninstalled. Or (maybe even more likely) trigger SELinux alerts if the policy disallows this (which should be true in most cases).
Comment 54 Ben Boeckel 2013-06-13 00:04:34 EDT
This works as of:

glib2-devel-2.37.1-1.fc20.x86_64

Can anyone confirm for F19 so this can be closed?
Comment 55 Nils Philippsen 2013-06-14 09:53:31 EDT
Works for me on F-18 and F-19:

glib2-devel-2.34.2-2.fc18
glib2-devel-2.36.3-1.fc19
Comment 56 Bill Gianopoulos 2013-06-14 10:43:28 EDT
Works for me also, and I am the original reporter.
Comment 57 Dwayne Fontenot 2013-06-14 13:05:08 EDT
And works for me on F19 (beta).
Comment 58 Fedora End Of Life 2013-07-04 03:01:31 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 59 Fedora End Of Life 2013-08-01 14:44:33 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 60 Felix Lu 2015-12-09 11:04 EST
Created attachment 1103971 [details]
conflicting systemtap tapset fix

The global variables in {32,64}-{gobject,glib}.stp
are conflicting.

See also, https://sourceware.org/bugzilla/show_bug.cgi?id=17587.

Systemtap 3.0 has introduced a "private" keyword to allow
limiting scope of globals.