Bug 466670 – media-libs/libsamplerate - Please add multilib ABI support

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Karl Lindén 2013-04-21 14:04:47 UTC]

media-libs/libsamplerate does currently not support multilib ABIs. The 32bit version of the library is instead available through app-emulation/emul-linux-x86-soundlibs. I am submitting a proposed ebuild supporting multilib through the autotools-multilib eclass.

Apart from adapting the ebuild to autotools-multilib eclass a blocker on app-emulation/emul-linux-x86-soundlibs has been added to prevent collisions.

I'm also attaching the diff between the new ebuild and the one in tree just for the overview.

[Comment 1 Karl Lindén 2013-04-21 14:05:21 UTC]

Created attachment 346194 [details]
The proposed ebuild with multilib ABI support.

[Comment 2 Karl Lindén 2013-04-21 14:06:21 UTC]

Created attachment 346196 [details, diff]
The difference between the new one and the one in tree.

[Comment 3 Alexis Ballier 2013-05-01 22:20:36 UTC]

+	amd64? ( abi_x86_32? ( !<=app-emultaion/emul-linux-x86-soundlibs-20130224 ) )"

not wrong but not consistent with the other ebuilds I've seen

+	export AT_M4DIR="M4"
+	autotools-multilib_src_prepare

AT_M4DIR="M4" autotools-multilib_src_prepare

-	emake DESTDIR="${ED}" htmldocdir="${EPREFIX}/usr/share/doc/${PF}/html" install
-	dodoc AUTHORS ChangeLog NEWS README

please define DOCS (saves some checks from using the default)

-	find "${ED}" -name '*.la' -exec rm -f '{}' +

missing AUTOTOOLS_PRUNE_LIBTOOL_FILES=all



nice work overall, thanks :)

[Comment 4 Michał Górny 2013-05-02 16:38:20 UTC]

Created attachment 347150 [details]
Updated conversion

This one should be ok for commit. Tests work fine for both ABIs, docs are the same.

[Comment 5 Michał Górny 2013-05-02 16:43:49 UTC]

Created attachment 347152 [details]
Updated r1

+ AUTOTOOLS_PRUNE_LIBTOOL_FILES=all.

[Comment 6 Alexis Ballier 2013-05-07 11:40:13 UTC]

(In reply to comment #5)
> Created attachment 347152 [details]
> Updated r1

it'd be easier to review with a diff:

-DESCRIPTION="Secret Rabbit Code (aka libsamplerate) is a Sample Rate Converter for audio"
+DESCRIPTION="Sample rate converter for audio"

unrelated and removing imho important information.

-	dodoc AUTHORS ChangeLog NEWS README


request from comment #3 still applies :)

[Comment 7 Michał Górny 2013-05-07 11:49:41 UTC]

(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 347152 [details]
> > Updated r1
> 
> it'd be easier to review with a diff:
> 
> -DESCRIPTION="Secret Rabbit Code (aka libsamplerate) is a Sample Rate
> Converter for audio"
> +DESCRIPTION="Sample rate converter for audio"
> 
> unrelated and removing imho important information.

Well, the usual rule is not to repeat the package name in DESCRIPTION. I don't know about the 'special' name though.

> -	dodoc AUTHORS ChangeLog NEWS README
> 
> 
> request from comment #3 still applies :)

You mean for performance reasons?

[Comment 8 Alexis Ballier 2013-05-07 11:57:42 UTC]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Created attachment 347152 [details]
> > > Updated r1
> > 
> > it'd be easier to review with a diff:
> > 
> > -DESCRIPTION="Secret Rabbit Code (aka libsamplerate) is a Sample Rate
> > Converter for audio"
> > +DESCRIPTION="Sample rate converter for audio"
> > 
> > unrelated and removing imho important information.
> 
> Well, the usual rule is not to repeat the package name in DESCRIPTION. I
> don't know about the 'special' name though.

yes but libsamplerate == SRC == secret rabbit code isn't obvious usually :)

> > -	dodoc AUTHORS ChangeLog NEWS README
> > 
> > 
> > request from comment #3 still applies :)
> 
> You mean for performance reasons?

performance doesn't really matter here, but rather for being clean (we known whats in the tarball, so why try to see what's in there and install it?) and easily catching removed docs on version bumps

[Comment 9 Michał Górny 2013-05-07 12:00:01 UTC]

(In reply to comment #8)
> > > -	dodoc AUTHORS ChangeLog NEWS README
> > > 
> > > 
> > > request from comment #3 still applies :)
> > 
> > You mean for performance reasons?
> 
> performance doesn't really matter here, but rather for being clean (we known
> whats in the tarball, so why try to see what's in there and install it?) and
> easily catching removed docs on version bumps

Well, that's a matter of taste, I guess. Then there's the other thing of catching new docs introduced on bumps :). Anyway, I'll add explicit DOCS back whenever they apply in the next-committed ebuilds.

[Comment 10 Alexis Ballier 2013-05-07 12:03:37 UTC]

(In reply to comment #9)
> Well, that's a matter of taste, I guess. Then there's the other thing of
> catching new docs introduced on bumps :). 

I've sometimes seen README files containing "see $webpage", such a file being completely useless shouldn't be installed

[Comment 11 Alexis Ballier 2013-07-29 22:35:22 UTC]

seems it has been fixed before hitting the tree