Gentoo Archives: gentoo-dev

From: Fabian Groffen <grobian@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] suspicious code in gnustep eclasses
Date: Sat, 31 Mar 2012 06:46:09
Message-Id: 20120331064523.GW10282@gentoo.org
In Reply to: [gentoo-dev] suspicious code in gnustep eclasses by "Paweł Hajdan
On 30-03-2012 13:00:33 +0200, "Paweł Hajdan, Jr." wrote:
> This is from gnustep-base.eclass: > > > egnustep_doc() { > > if [[ -d ./Documentation ]] ; then > > # Check documentation presence > > cd "${S}"/Documentation > > if [[ -f ./[mM]akefile || -f ./GNUmakefile ]] ; then > > emake "${GS_ENV[@]}" all || die "doc make failed" > > emake "${GS_ENV[@]}" install || die "doc install failed" > > fi > > cd .. > > fi > > } > > Shouldn't those cd calls above rather be pushd/popd? It seems the above > assumes that CWD is "${S}" when egnustep_doc is executed, which is > probably true, but pushd/popd seems just safer.
Go ahead.
> Also, instead of ./Documentation, "${S}/Documentation" could be used.
Given the following cd, I tend to agree.
> This is from gnustep-2.eclass: > > > RDEPEND="${DEPEND} > > debug? ( >=sys-devel/gdb-6.0 )" > > Is there some gnustep crash-reporting tool that uses gdb? I think it's > reasonable for USE="debug" to influence how things are compiled, but > unless gdb is required for something to work, it should be up to the > user to install or not install gdb. > > In case something is broken with <gdb-6.0, please consider two points: > > - there is no <gdb-6.0 in the tree now > - you could add a blocker on <gdb-6.0 instead, which is not going to > disrupt developers because there is no such version in the tree anyway, > and we have up-to-date systems
I think the version is because GNUstep is written in Objective-C. That said, I think your blocker approach would be fine. -- Fabian Groffen Gentoo on a different level

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies