affects me as well. I did not force installing those libxslt packages.

workaround: remove libxslt-devel, upgrade to 26, worked for me.

Error: Transaction check error:
  file /usr/bin/xslt-config from install of libxslt-devel-1.1.29-4.fc27.i686 conflicts with file from package libxslt-devel-1.1.29-4.fc27.x86_64
  file /usr/include/libxslt/xsltconfig.h from install of libxslt-devel-1.1.29-4.fc27.i686 conflicts with file from package libxslt-devel-1.1.29-4.fc27.x86_64

This is still a bug in Fedora27

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

This bug affects Fedora 27 and rawhide as well.

(In reply to jakkul from comment #2)

Can't work as these packages contain different files: bin/xslt-config and include/libxslt/xsltconfig.h. Both can be trivially patched to work under x86_64 and i686 simultaneously but it looks like the maintainer of this package is MIA or has stopped caring.

I could have sent the patches in but I'm pretty sure the bug won't be fixed until the maintainer gets replaced or someone from RedHat/Fedora steps in to resolve this issue.

I filed a similar bug for another package a while ago
https://bugzilla.redhat.com/show_bug.cgi?id=1481351 , and even went as far as testing and submitting a patch. But I got shot down more than a few times as "Fedora does not support multiarch...".

The maintainer for that package is responsive to comments, but not co-operative.

I mean - what's wrong with just accepting a patch I submitted and close the bug as fixed (instead of "NOT A BUG, Fedora does not support multiarch" and just rejecting the patch without looking)? A few dozen other packages have a similar set up and support multiarch...

Many fedora packages have a *-32.h and a *-64.h and use a wrapper *.h to dispatch to either depending on wordsize. See my patch on the other bug report and my comments there.

Created attachment 1382851 [details]
libxslt-multilib.patch

(In reply to Hin-Tak Leung from comment #7)

> "Fedora does not support multiarch...".

Whoever said that must be fired and never work for/with Fedora ever again.

> Many fedora packages have a *-32.h and a *-64.h and use a wrapper *.h to dispatch to either depending on wordsize.

That's not necessary. I've actually gone ahead and written a very basic patch which Just Works™.

The only problem now is to find a proper person at Fedora/RedHat to ask to apply this patch.

Also, please change Fedora's version to 27 to make this bug report a little bit more actual.

This bug report falls under https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

(In reply to Hin-Tak Leung from comment #8)

Please follow this link https://pagure.io/fesco/new_issue and file a report on this bug report.

This bug report has seen zero responses for 7 months which automatically makes this maintainer unfit for its job (whatever his/her reasons are).

(In reply to Artem S. Tashkinov from comment #9)
> Created attachment 1382851 [details]
> libxslt-multilib.patch

Thanks for spending time on this.

> (In reply to Hin-Tak Leung from comment #7)
> 
> > "Fedora does not support multiarch...".
> 
> Whoever said that must be fired and never work for/with Fedora ever again.

I have seriously thought about finding somebody higher up in the hierarchy to have this guy's maintainer status revoked, based on his responses:

https://bugzilla.redhat.com/show_bug.cgi?id=1481351#c4
"
And the way to do it is to use mock (or other chroot) to build the 32-bit package in a true 32-bit environment. Any other way is not supported in Fedora.
"

https://bugzilla.redhat.com/show_bug.cgi?id=1481351#c5
"Multiarched packages are for *compatibility* only, not development."

https://bugzilla.redhat.com/show_bug.cgi?id=1481351#c9
"Again, multiarch is only for binary compability in Fedora. If you want to develop 32-bit applications, use a chroot or mock."

https://bugzilla.redhat.com/show_bug.cgi?id=1481351#c12
"...Nobody wants to build a 32-bit library on a 64-bit host. We build 64-bit libraries on 64-bit hosts, and 32-bit libraries on 32-bit hosts. Multiarch allows you to keep using 32-bit applications on a 64-bit host; the packages are pulled from the 32-bit build. BUILDING 32-BIT APPLICATIONS ON 64-BIT FEDORA IS NOT SUPPORTED IN ANY WAY IN FEDORA!"

> Also, please change Fedora's version to 27 to make this bug report a little
> bit more actual.

done.

(In reply to Hin-Tak Leung from comment #11)
> done.

I don't see any changes.

Again, please follow this link https://pagure.io/fesco/new_issue and file a report on this maintainer.

Igor, could you please pull some strings on the libxslt package? It's old, seemingly unmaintained, contains multiple memory leaks and other problems and there are even open CVE's against the version which comes in Fedora.

Please send Pull Request on src.fedoraproject.org, I will happily check & merge.

Thanks!

(In reply to Igor Gnatenko from comment #14)

Igor,

Can we please have a maintainer for libxslt instead? I don't have a desire to create an account at fedoraproject and I'm even less willing to go through the hassle of doing any more work.

It's a working patch, it applies cleanly - I don't understand why someone else at Fedora/RH cannot apply it.

(In reply to Artem S. Tashkinov from comment #15)
> (In reply to Igor Gnatenko from comment #14)
> 
> Igor,
> 
> Can we please have a maintainer for libxslt instead? I don't have a desire
> to create an account at fedoraproject and I'm even less willing to go
> through the hassle of doing any more work.

That's who I am.

Unfortunately, it is very very low priority in my TODO list to fix this bug myself.

> It's a working patch, it applies cleanly - I don't understand why someone
> else at Fedora/RH cannot apply it.

I will try it out when I will get some free time.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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
EOL if it remains open with a Fedora  'version' of '27'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 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 this bug is closed as described in the policy above.

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.

Please open Pull Request on https://src.fedoraproject.org/rpms/libxslt.

Same a previous time. I still don't have enough time. If you don't submit PR by end of this month, I'll do it myself. But this month is full.

Just FYI: This is also present in RHEL 8
...
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
  file /usr/bin/xslt-config from install of libxslt-devel-1.1.32-3.el8.i686 conflicts with file from package libxslt-devel-1.1.32-3.el8.x86_64
  file /usr/include/libxslt/xsltconfig.h from install of libxslt-devel-1.1.32-3.el8.i686 conflicts with file from package libxslt-devel-1.1.32-3.el8.x86_64

...

The patch has been added to the Fedora spec but not applied ...

(In reply to Paul Howarth from comment #20)
> The patch has been added to the Fedora spec but not applied ...

Whoops, my error; I was just looking at the commit and didn't notice the spec was using %autosetup.

Is there a chance this update is going to be pushed to Fedora 30?