Bug 474654 – media-gfx/exiv2 multilib support

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Michael Weber (RETIRED) 2013-06-25 00:57:21 UTC]

-

[Comment 1 Michael Weber (RETIRED) 2013-07-20 14:24:13 UTC]

Created attachment 353722 [details, diff]
ebuild patch

[Comment 2 Pacho Ramos 2013-08-23 11:05:00 UTC]

(don't forget to CC multilib, specially in packages like this that are orphan)

[Comment 3 Johannes Huber (RETIRED) 2013-12-20 11:37:07 UTC]

Thanks for reporting. This is fixed in cvs. Please sync.

+
+  20 Dec 2013; Johannes Huber <[e-mail]> +exiv2-0.23-r2.ebuild:
+  Revision bump adds multilib support + converted to python-single-r1 eclass by
+  Michael Weber <[e-mail]>, bug #474654. Introduces subslot, bug #456794.
+

[Comment 4 Alex Turbov 2013-12-21 02:50:12 UTC]

Unable to build exiv2 w/ USE=doc enabled using this ebuild:

relevant build log pieces:


 * amd64: running emake doc
make -j4 doc
make: Nothing to be done for 'doc'.
<skipped>
 * amd64: running dohtml -r doc/html/.
!!! Don't know what to do with 'doc/html/.'


The only ABI enabled at my host is 64bit.

I've add a "multilib_for_best_abi pwd -P" before install and "emake doc" lines of the ebuild and got the following.

 * amd64: running pwd -P
/storage/tmp/paludis/media-gfx-exiv2-0.23-r2/work/exiv2-0.23

note, it points to a dir w/o ABI suffix! it is why it can't build any docs...

[Comment 5 Michał Górny 2014-01-15 10:18:57 UTC]

Guys, this thing is terrible.

1) You don't have proper multilib dependencies. In fact, the dependencies aren't even multilib. The package randomly fails to build from system to system.

2) The dependencies for this package haven't been converted to multilib yet. You can't convert it properly right now.

3) You use autotools-multilib completely incorrect. No call to src_prepare, explicit copy_sources without making the eclass aware it's running like this...

4) You're calling python_* functions that don't even exist in the eclass...

5) You apply ABI-specific arguments in common src_configure(). They will get applied to the x86 build incorrectly.

The whole thing is full of hackery, doing things the hardest way possible and bugs. I don't understand why it was committed without proper testing and/or review by multilib@.

I will take the liberty of masking this package before we find even more breakage in it.

[Comment 6 Michał Górny 2014-01-15 12:10:08 UTC]

Created attachment 367894 [details, diff]
Proper patch against -r1

Few notes:

1. I've cleaned it up a little -- added missing ||die, removed unnecessary ||die,

2. I've switched the ebuild to python-any-r1 -- the Python dep is purely build-time,

3. I've converted it to multilib properly, with proper deps.

You need to wait for libintl before committing it.

[Comment 7 Michał Górny 2014-01-15 12:10:40 UTC]

Created attachment 367896 [details]
Full -r3 ebuild

[Comment 8 Johannes Huber (RETIRED) 2014-02-09 14:58:48 UTC]

(In reply to Michał Górny from comment #7)
> Created attachment 367896 [details]
> Full -r3 ebuild

@Michał go ahead

[Comment 9 Michał Górny 2014-02-09 22:09:50 UTC]

Just to be clear, does anything actually need exiv2 multilib? I mean, anything that ends up with a real program and not library someone made multilib-enabled for fun.

[Comment 10 Michał Górny 2014-04-30 14:28:39 UTC]

+  30 Apr 2014; Michał Górny <[e-mail]> exiv2-0.23-r2.ebuild:
+  Fix multilib and Python support. Bug #474654.