Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
On Fri, 2009-10-09 at 16:13 -0700, Adam Williamson wrote:
On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
Actually this is a bug. If the packages are offered in the same repo, they should install together (barring explicit conflicts listed in the spec file). Looks like the example makefile may be generated at build time, or touched in someway so that it is different when on i686 and x86_64. That should not happen, they should be the same.
Jesse Keating wrote:
On Fri, 2009-10-09 at 16:13 -0700, Adam Williamson wrote:
On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
Actually this is a bug. If the packages are offered in the same repo, they should install together (barring explicit conflicts listed in the spec file). Looks like the example makefile may be generated at build time, or touched in someway so that it is different when on i686 and x86_64. That should not happen, they should be the same.
Both /usr/bin/libotf-config and example/Makefile are autoconf-generated. Suggestions?
On Fri, Oct 09, 2009 at 04:13:22PM -0700, Adam Williamson wrote:
On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
I believe this is incorrect. devel packages are supposed to be multilib installable. There's two things that are two files that conflict above and there's two different fixes for each. /usr/bin/libotf-config -- This is a script or binary for the user to run. It likely has different library paths depending on whether we're installing on x86_64 or i386. One of the better ways to fix this is to make libotf-config into a wrapper around pkg-config and then send the modifications to upstream. pkg-config stores the data filesabout each library in %{_libdir}/pkgconfig so it's multilib safe. If upstream doesn't want that or the libotf-config script has very different ideas of what information it needs to give out than pkg-config, renaming the binary to libotf-config32 and libotf-config64 is another method. However, this has the drawback of requiring patches to code which invokes libotf-config in other packages. The pkg-config wrapper is greatly prefered.
Makefile -- You'll have to download the two packages and check what's changed in the Makefile. Perhaps it's hardcoding the installed library path needlessly or youcanuse pkg-config/libotf-config to make the Makefile the same onall arches. If you get stuck you can post the diff of the Makefiles here and we can help more.
There are some methods of working around these issues here: https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks -Toshio
On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
I believe this is incorrect. devel packages are supposed to be multilib installable. There's two things that are two files that conflict above and there's two different fixes for each.
I'm happy to be wrong :), but is this documented anywhere? That's why I thought the opposite was the case, I couldn't find anything to this effect in the packaging documentation when I was starting out.
It seems like a lot of work for very little return if it is our policy, especially fiddling around with *-config and the like executables, which are far from uncommon...what's the use case for multilib -devel packages? When is it actually useful to have both arches installed at once for a -devel package?
Adam Williamson wrote:
On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
I believe this is incorrect. devel packages are supposed to be multilib installable. There's two things that are two files that conflict above and there's two different fixes for each.
I'm happy to be wrong :), but is this documented anywhere? That's why I thought the opposite was the case, I couldn't find anything to this effect in the packaging documentation when I was starting out.
It seems like a lot of work for very little return if it is our policy, especially fiddling around with *-config and the like executables, which are far from uncommon...what's the use case for multilib -devel packages? When is it actually useful to have both arches installed at once for a -devel package?
Fortunately, it seems that this particular case (2 file conflicts) was pretty easy to fix (just remove the offending files). Looking at emacs-23.1, it appears to be using pkgconfig, and libotf already was installing a proper libotf.pc. I'm hoping /usr/bin/libotf-config isn't essential.
On Fri, 9 Oct 2009, Adam Williamson wrote:
On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
I believe this is incorrect. devel packages are supposed to be multilib installable. There's two things that are two files that conflict above and there's two different fixes for each.
I'm happy to be wrong :), but is this documented anywhere? That's why I thought the opposite was the case, I couldn't find anything to this effect in the packaging documentation when I was starting out.
Well, I know it is documented that file conflicts are never allowed, ever, at all w/o an explicit conflicts: in the spec file.
-sv
On Fri, 2009-10-09 at 22:25 -0400, Seth Vidal wrote:
On Fri, 9 Oct 2009, Adam Williamson wrote:
On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:
It's not to be considered a bug, AFAIK. We don't stipulate that development packages be installable side-by-side in this way, we only stipulate that for library packages where there's a need for it. There's no particular use case where you absolutely need both -devel packages installed at once.
I believe this is incorrect. devel packages are supposed to be multilib installable. There's two things that are two files that conflict above and there's two different fixes for each.
I'm happy to be wrong :), but is this documented anywhere? That's why I thought the opposite was the case, I couldn't find anything to this effect in the packaging documentation when I was starting out.
Well, I know it is documented that file conflicts are never allowed, ever, at all w/o an explicit conflicts: in the spec file.
Ah, yeah. That would cover it without any need for a specific multilib policy, for sure. (I checked, and libotf-devel i686 is in the x86-64 repo).
Of course, that turns the larger question into 'why do we put i686 -devel packages in the x86-64 repo, not just the lib packages', but it does explain for sure that I was wrong in my initial reply, sorry for that!
On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:
Of course, that turns the larger question into 'why do we put i686 -devel packages in the x86-64 repo, not just the lib packages',
Because not all files in -devel packages cover multiple target platforms. Example: You could not build for i686 with headers that are specific to x86_64, and you would also need the .so symlinks for libraries in the appropriate libdir.
On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote:
On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:
Of course, that turns the larger question into 'why do we put i686 -devel packages in the x86-64 repo, not just the lib packages',
Because not all files in -devel packages cover multiple target platforms. Example: You could not build for i686 with headers that are specific to x86_64, and you would also need the .so symlinks for libraries in the appropriate libdir.
Well, that's only valid if we actually do anything to ensure multilib compilation actually *works*, right now all we enforce is that the packages don't conflict (which isn't the same thing at all). I hope I'm not dragging him into the conversation unwillingly, but Colin Walters raised those points on IRC:
<walters> well, what's the ultimate goal? just avoiding the OS exploding if you happen to somehow get an i386 -devel? or actually be able to compile 32 bit on 64 hosts? <walters> those are pretty different things
...
<walters> people keep trying to scope creep multilib to include compilation, which we need to clamp down on, and tell them to use mock <Oxf13> well last time we tried to make major changes to our multilib strategy, Jeremy was the one to play Captain No and he's gone now, so....
I guess the point is that if we actually intend to support 'you can cross-compile with any -devel package from another arch that's included in the repository' we may need more strict policies / work to ensure that's actually possible, and if we intend *not* to support that, but rather tell people to use mock, there's no reason to include -devel packages in multilib.
On Sat, 2009-10-10 at 10:17 -0700, Adam Williamson wrote:
I guess the point is that if we actually intend to support 'you can cross-compile with any -devel package from another arch that's included
gah, I know I don't really mean cross-compile, it's been pointed out to me before that it's the wrong term. you know what I mean. sorry.
On Sat, Oct 10, 2009 at 10:17:16AM -0700, Adam Williamson wrote:
Well, that's only valid if we actually do anything to ensure multilib compilation actually *works*, right now all we enforce is that the packages don't conflict (which isn't the same thing at all).
It's also valid if we want to help people to be able to have multilib compilation work, even if it is not used in fedora rpm builds. I have no knowledge about this issue, but I guess that having multilib devel packages installed allows users comppiling software to easily use one or the other library, even if it involves setting some flags by hand, and, hopefully, with pkg-config setting flags by hand is not required.
-- Pat
On Sat, Oct 10, 2009 at 10:17:16AM -0700, Adam Williamson wrote:
On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote:
On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:
Of course, that turns the larger question into 'why do we put i686 -devel packages in the x86-64 repo, not just the lib packages',
Because not all files in -devel packages cover multiple target platforms. Example: You could not build for i686 with headers that are specific to x86_64, and you would also need the .so symlinks for libraries in the appropriate libdir.
Well, that's only valid if we actually do anything to ensure multilib compilation actually *works*, right now all we enforce is that the packages don't conflict (which isn't the same thing at all). I hope I'm not dragging him into the conversation unwillingly, but Colin Walters raised those points on IRC:
Well.. not really. it's valid if the goal is to allow people to do multilib compilation. Testing that the goal hasbeen met is a separate issue.
As for feature creep -- that may be. I'm operating under the assumption that this is a feature as there was amessage to the list stating that this was a current goal. It could be that someone posted it but it was only their opinion of what needed to be done, not an actual fact. Would someone or someones care to put this up for discussion at FESCo and present rationale for and against it?
-Toshio
Adam Williamson wrote:
On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote:
On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:
Of course, that turns the larger question into 'why do we put i686 -devel packages in the x86-64 repo, not just the lib packages',
Because not all files in -devel packages cover multiple target platforms. Example: You could not build for i686 with headers that are specific to x86_64, and you would also need the .so symlinks for libraries in the appropriate libdir.
Well, that's only valid if we actually do anything to ensure multilib compilation actually *works*, right now all we enforce is that the packages don't conflict (which isn't the same thing at all).
Well... at $DAYJOB we *depend* on being able to compile 32-bit on 64-bit for at least a couple products. And not just on Red Hat (and in my case, Fedora), but also on Solaris, HP-UX, Darwin and AIX, all of which support this just fine. (Yes, "all" includes Fedora/RH, at least for the admittedly limited set of libs we use.)
That said, I'm not asking for it to be actually tested in Fedora, just that if it breaks and I complain, the reply won't be "we don't care because that is not supported and therefore it will not be fixed". IOW I am fine with the current status quo, but I don't want to see multilib dropped (not even sure it can be due to wine) or the policy otherwise become explicitly hostile toward multilib compilation.
Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
If the contents of the file is the same and they only their timestamps differ, you can touch them reversely after install as in http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1...
Regards, Christoph
On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote:
Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
If the contents of the file is the same and they only their timestamps differ, you can touch them reversely after install as in http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1...
What if the generated docbook documents are different due to different "id"s? Do we need to separate the docs into a noarch subpackage?
Orcan
Am Freitag, den 09.10.2009, 19:48 -0400 schrieb Orcan Ogetbil:
On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote:
...
If the contents of the file is the same and they only their timestamps differ, you can touch them reversely after install as in http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1...
What if the generated docbook documents are different due to different "id"s? Do we need to separate the docs into a noarch subpackage?
Honestly I have no idea, but I prefer noatch subpackages for docs anyway. Of course, this depends on their size.
Orcan
Regards, Christoph
On 10/10/2009 01:48 AM, Orcan Ogetbil wrote:
On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote:
Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:
What if the generated docbook documents are different due to different "id"s? Do we need to separate the docs into a noarch subpackage?
Nope, this doesn't actually help.
The actual fix would be to fix docbook[1] rsp. these docbook-documents' sources to not apply "ids" rsp. to produce "deterministic ids".
An alternative work-around would be to "filter out/process" (e.g. by using sed) these "id"s, such the generated docs can be generated deterministically.
Last resort would be to move such docs into arch' dependent directories in arch-dependent packages.
Ralf
On Sat, 10 Oct 2009, Christoph Wickert wrote:
Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
If the contents of the file is the same and they only their timestamps differ, you can touch them reversely after install as in http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1...
Timestamp differences do NOT cause file conflicts. Content (and permission) differences do.
- Panu -
Am Samstag, den 10.10.2009, 11:30 +0300 schrieb Panu Matilainen:
On Sat, 10 Oct 2009, Christoph Wickert wrote:
If the contents of the file is the same and they only their timestamps differ, you can touch them reversely after install as in http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1...
Timestamp differences do NOT cause file conflicts.
Indeed, obviously this has changed. Changes like this should be announced somewhere, I guess Kevin and me are not the only one packagers who still believe they have to care for timestamps.
Content (and permission) differences do.
I took a look at the files from exo and they did differ. Tanks for the pointer.
- Panu -
Regards, Christoph
On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote:
Timestamp differences do NOT cause file conflicts.
Indeed, obviously this has changed. Changes like this should be announced somewhere, I guess Kevin and me are not the only one packagers who still believe they have to care for timestamps.
I am not sure that timestamps created conflicts in the past. However in rpm -V there were marked as being modified. Maybe this is what changed. In any case I think that we should care for timestamps even if they are not reasons for conflicts. Some packagers disagree, though, that timestamps are useful and should be correct.
-- Pat
On Sat, 10 Oct 2009 17:32:40 +0200, Patrice wrote:
On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote:
Timestamp differences do NOT cause file conflicts.
Indeed, obviously this has changed. Changes like this should be announced somewhere,
What is the source of these rumours that file timestamp differences would cause conflicts?
I guess Kevin and me are not the only one packagers who still believe they have to care for timestamps.
I am not sure that timestamps created conflicts in the past.
If they have ever lead to conflicts, then only as a result of a temporary bug.
Michael Schwendt wrote, at 10/11/2009 01:09 AM +9:00:
On Sat, 10 Oct 2009 17:32:40 +0200, Patrice wrote:
On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote:
Timestamp differences do NOT cause file conflicts.
Indeed, obviously this has changed. Changes like this should be announced somewhere,
What is the source of these rumours that file timestamp differences would cause conflicts?
I guess these rumors came because sometimes some programs creating document files (mostly html files) or so embeded the timestamp of the date in those files and that actually caused multilib conflict (i.e. not the timestamp of the files but the embedded strings in those files).
Regards, Mamoru
I received the following from upstream. Anyone know the answer to the question (how do freetype-config, etc workaround this issue?)
In article 200910092117.36851.ndbecker2@gmail.com, Neal Becker ndbecker2@gmail.com writes:
I maintain libotf for Fedora.
Thank you very much for that work!
We have received a bug report of a multilib conflict, which occurs when installing development packages for both i586
and
x86_64. The problem is /usr/bin/libotf-config, which occurs in both
packages
but is not identical.
My solution is to remove this file. I'm hoping it's not really needed. libotf already has package-config support (which is multilib compatible already), so if all apps use package-config there should be no problem.
Are there any apps that need /usr/bin/libotf-config to your knowledge?
As far as I know, there's none. So, it's ok to remove libotf-config. But, why does libotf-config don't work with multilib? How do the other XXX-config programs (e.g. freetype-config, fribidi-config, gtk-config, ...) work with multilib?
Neal Becker ndbecker2@gmail.com writes:
I received the following from upstream. Anyone know the answer to the question (how do freetype-config, etc workaround this issue?)
freetype-config is just a wrapper around pkg-config.
Andreas.
On Tue, Oct 13, 2009 at 07:10:06AM -0400, Neal Becker wrote:
As far as I know, there's none. So, it's ok to remove libotf-config. But, why does libotf-config don't work with multilib? How do the other XXX-config programs (e.g. freetype-config, fribidi-config, gtk-config, ...) work with multilib?
In many cases, conflict arise because there is a -L%{_libdir} which is not needed anyway since it is already on the search path. Otherwise it is possible for upstream to ship and old-style *-config script and a wrapper around pkgconfig such that, as a packager you can chose to install the wrapper around pkgconfig. If I recall well, this is what is done in libdap.
-- Pat