Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 458638

Summary: app-emulation/emul-linux-x86-*: include 32bit libexif (was: USE="multilib" for 32bit build)
Product: Gentoo Linux Reporter: Mario Kicherer <dev>
Component: New packagesAssignee: AMD64 Project <amd64>
Status: RESOLVED FIXED    
Severity: enhancement CC: andriy.tsykholyas, graphics+disabled, hasufell, junghans, mgorny, ssuominen
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 454644, 165270    
Attachments: libexif-multilib.patch
libexif-0.6.21.ebuild.diff
libexif-0.6.21.ebuild.diff

Description Mario Kicherer 2013-02-21 22:18:53 UTC
I wrote a patch for libexif to support multilib builds. The 32bit version is required on amd64 systems for a mono-based game, see bug #446682.

Reproducible: Always
Comment 1 Mario Kicherer 2013-02-21 22:19:22 UTC
Created attachment 339644 [details, diff]
libexif-multilib.patch
Comment 2 Christoph Junghans (RETIRED) gentoo-dev 2013-02-21 23:07:54 UTC
Comment on attachment 339644 [details, diff]
libexif-multilib.patch

>--- libexif-0.6.21.ebuild	2012-11-07 20:31:19.000000000 +0100
>+++ libexif-0.6.21-r1.ebuild	2013-02-21 21:30:45.165734741 +0100
>@@ -11,10 +11,15 @@
>-KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~x64-solaris ~x86-solaris"
>+KEYWORDS="~amd64"
Just move all keywords to ~arch.

>@@ -23,19 +28,22 @@
> src_prepare() {
> 	epatch "${FILESDIR}"/${PN}-0.6.13-pkgconfig.patch
Could go into PATCHES.

Otherwise, great job.
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2013-02-22 00:25:27 UTC
so as per current policy, this bug belongs to amd64@ and libexif should go to one of the emul-linux-x86-* packages

most definately not going to convert these ebuilds to autotools-multilib, and be forced upon the unnecessary autotools-utils format
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-02-22 09:23:26 UTC
(In reply to comment #3)
> so as per current policy, this bug belongs to amd64@ and libexif should go
> to one of the emul-linux-x86-* packages
> 
> most definately not going to convert these ebuilds to autotools-multilib,
> and be forced upon the unnecessary autotools-utils format

Then just use multilib-build and prove how intelligent you are.
Comment 5 Christoph Junghans (RETIRED) gentoo-dev 2013-02-22 16:34:24 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > so as per current policy, this bug belongs to amd64@ and libexif should go
> > to one of the emul-linux-x86-* packages
> > 
> > most definately not going to convert these ebuilds to autotools-multilib,
> > and be forced upon the unnecessary autotools-utils format
> 
> Then just use multilib-build and prove how intelligent you are.
I agree, the changes due to autotools-multilib are minimal, so what's the point and emul-linux-x86-* should go away, but you are somehow suggesting the opposite.
Comment 6 Pacho Ramos gentoo-dev 2013-02-22 21:42:47 UTC
I also strongly disagree on adding more packages to emul set... even if I also agree would be nice to not need to rely on autotools-utils.eclass always... but in this case I don't understand why autotools-utils.eclass should be avoided :/
Comment 7 Julian Ospald 2013-02-23 02:27:35 UTC
if people are unable for consensus in this matter then I will add a new package
app-emulation/emul-linux-x86-steam

the situation has to improve, steam is attracting a WIDE user base that can benefit us as a distro


@ Samuli ...would you be willing to accept a patch that uses multilib-build instead?
Comment 8 Samuli Suominen (RETIRED) gentoo-dev 2013-02-23 06:09:55 UTC
(In reply to comment #7)
> @ Samuli ...would you be willing to accept a patch that uses multilib-build
> instead?

yes, i'd very much love to see plain multilib-build based ebuild. minimal changes.
Comment 9 Christoph Junghans (RETIRED) gentoo-dev 2013-02-23 18:43:20 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > @ Samuli ...would you be willing to accept a patch that uses multilib-build
> > instead?
> 
> yes, i'd very much love to see plain multilib-build based ebuild. minimal
> changes.
multilib-build.eclass makes use of BUILD_DIR, which is not implemented in plain EAPI phase functions, one could achieve something similar by using ECONF_SOURCE, but not with minimal changes to the ebuild. We could put the necessary code into a new multilib-eapi.eclass, but I don't see an advantage in that over the current solution.
Comment 10 Julian Ospald 2013-02-23 20:09:56 UTC
Created attachment 339840 [details, diff]
libexif-0.6.21.ebuild.diff
Comment 11 Pacho Ramos gentoo-dev 2013-02-23 20:27:45 UTC
Maybe that BUILD_DIR handling could be moved to a different eclass as probably more developers will refuse to migrate their packages to autotools-utils.eclass :/
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-02-23 21:24:11 UTC
(In reply to comment #11)
> Maybe that BUILD_DIR handling could be moved to a different eclass as
> probably more developers will refuse to migrate their packages to
> autotools-utils.eclass :/

So we should reinvent the wheel in another eclass just to prove that Gentoo developers belong to the group of people who refuse stuff just because of its name?
Comment 13 Julian Ospald 2013-02-23 21:27:41 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Maybe that BUILD_DIR handling could be moved to a different eclass as
> > probably more developers will refuse to migrate their packages to
> > autotools-utils.eclass :/
> 
> So we should reinvent the wheel in another eclass just to prove that Gentoo
> developers belong to the group of people who refuse stuff just because of
> its name?

No, it's because autotools-utils.eclass does more implicit stuff, much like base.eclass.

Some devs don't like to depend too much on automated eclass mechanics if it's not evidently necessary.
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-02-23 22:11:29 UTC
(In reply to comment #13)
> No, it's because autotools-utils.eclass does more implicit stuff, much like
> base.eclass.
> 
> Some devs don't like to depend too much on automated eclass mechanics if
> it's not evidently necessary.

...which is?
Comment 15 Julian Ospald 2013-02-23 22:20:15 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > No, it's because autotools-utils.eclass does more implicit stuff, much like
> > base.eclass.
> > 
> > Some devs don't like to depend too much on automated eclass mechanics if
> > it's not evidently necessary.
> 
> ...which is?

no, autotools-multilib could also work without autotools-utils

so that one would just need to convert src_compile() to multilib_src_compile()
Comment 16 Julian Ospald 2013-02-24 00:16:56 UTC
Created attachment 339884 [details, diff]
libexif-0.6.21.ebuild.diff

removed unneeded app-emulation/emul-linux-x86-baselibs from deps
Comment 17 Samuli Suominen (RETIRED) gentoo-dev 2013-02-26 23:52:07 UTC
So we are waiting for proper eclass to be committed:
http://www.gossamer-threads.com/lists/gentoo/dev/268765

Otherwise this will be a no-go
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-02-27 07:11:08 UTC
Samuli, could you please try to be more mature and don't expect special eclass just for you?
Comment 19 Pacho Ramos gentoo-dev 2013-02-27 07:17:50 UTC
(In reply to comment #18)
> Samuli, could you please try to be more mature and don't expect special
> eclass just for you?

Maybe the way to go would be to agree in what autotools-utils.eclass features are not wanted by people. 

From my point of view, I see no problem in PATCHES/AUTORECONF handling (as it's completely optional), .la files removal could be done configurable in a similar way it's done in gnome2.eclass for eapi5, static-libs feature also looks useful to me (and I think can be preserved as it's only used when "static-libs" is in USE). About DOCS handling I don't fully understand the reasons for including it, is it for supporting arrays?
Comment 20 Samuli Suominen (RETIRED) gentoo-dev 2013-02-27 09:12:44 UTC
(In reply to comment #18)
> Samuli, could you please try to be more mature and don't expect special
> eclass just for you?

special eclass? more like generic eclass without the unnecessary cruft

(In reply to comment #19)
> Maybe the way to go would be to agree in what autotools-utils.eclass
> features are not wanted by people. 

everything unrelated to the multilib conversion is unwanted. only useful bit from autotools-utils.eclass is the out-of-source build support

but I guess none of this is relavent now that hasufell told me the eclass won't be committed and the another eclass shouldn't be used either in favour of multilib-portage
people should make up their mind
Comment 21 Alexis Ballier gentoo-dev 2013-02-27 09:42:46 UTC
(In reply to comment #20)
> but I guess none of this is relavent now that hasufell told me the eclass
> won't be committed and the another eclass shouldn't be used either in favour
> of multilib-portage
> people should make up their mind

hu? yes the eclass duplicates the multilib-portage behavior, but with in addition correct multilib useflags and the possibility to specify the correct multilib usedeps in packages instead of the implicit foo[multilib?] done by multilib-portage which is way suboptimal.
Comment 22 Mario Kicherer 2013-02-27 10:38:24 UTC
I don't know if this has any relevance but from a beginner's perspective the ebuild with autotools-multilib.eclass looks much easier and cleaner (49 vs 68 lines). Of course, I do not understand everything what's happening behind but in general I would say less complexity in an ebuild is a good thing - even if it's doing things more complicated than necessary. At least it works without much effort for the few ebuilds I patched so far and they require even less code now.
Comment 23 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-02-27 22:23:16 UTC
(In reply to comment #20)
> (In reply to comment #18)
> > Samuli, could you please try to be more mature and don't expect special
> > eclass just for you?
> 
> special eclass? more like generic eclass without the unnecessary cruft

That doesn't matter. It's the eclass we have for autotools and you don't have real technical arguments against it. So far, it boils down to you wanting additional eclass because you dislike the style of autotools-utils.

We can work on a compromise but so far, you have been expecting me to introduce changes breaking most of the tree. If you can't get a real compromise, I'm afraid that you alone aren't supposed to decide on introducing a redundant eclass.

> (In reply to comment #19)
> > Maybe the way to go would be to agree in what autotools-utils.eclass
> > features are not wanted by people. 
> 
> everything unrelated to the multilib conversion is unwanted. only useful bit
> from autotools-utils.eclass is the out-of-source build support

Ebuilds aren't developer's playground. You are not supposed to refuse to use the eclass we have just because you don't like some of the features which don't even change anything in your case.

> but I guess none of this is relavent now that hasufell told me the eclass
> won't be committed and the another eclass shouldn't be used either in favour
> of multilib-portage
> people should make up their mind

No offense but hasufell is jumping from flower to flower (meaning may have been lost in translation) lately. I'm afraid he is too fast to judge and put work on stuff.
Comment 24 Julian Ospald 2013-03-04 22:08:53 UTC
(In reply to comment #23)
> 
> > (In reply to comment #19)
> > > Maybe the way to go would be to agree in what autotools-utils.eclass
> > > features are not wanted by people. 
> > 
> > everything unrelated to the multilib conversion is unwanted. only useful bit
> > from autotools-utils.eclass is the out-of-source build support
> 
> Ebuilds aren't developer's playground. You are not supposed to refuse to use
> the eclass we have just because you don't like some of the features which
> don't even change anything in your case.

That is simply wrong.

Eclasses provide convenient functions for optional use in ebuilds. Whether a developer wants to use them or not is totally up to him.

If he breaks something by not using proper eclass functions (especially for stuff like ruby or python), then you can blame him, otherwise not.


> 
> > but I guess none of this is relavent now that hasufell told me the eclass
> > won't be committed and the another eclass shouldn't be used either in favour
> > of multilib-portage
> > people should make up their mind
> 
> No offense but hasufell is jumping from flower to flower (meaning may have
> been lost in translation) lately. I'm afraid he is too fast to judge and put
> work on stuff.

I will commit the discussed eclass multilib-minimal this week. If you don't respond to it beforehand... *shrug*. I asked more than once for a review and it's a pretty simple eclass.

No one said "omg", so I take that as a yes despite your non-technical ad hominem arguments.
Comment 25 Julian Ospald 2013-03-09 21:01:54 UTC
+*libexif-0.6.21-r1 (09 Mar 2013)
+
+  09 Mar 2013; Julian Ospald <hasufell@gentoo.org> +libexif-0.6.21-r1.ebuild:
+  convert to multilib-minimal wrt #458638