Re: [gentoo-dev] virtualx eclass possible issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 12.3.2011 11:37, Paweł Hajdan, Jr. napsal(a):
One of my ebuilds is using virtualx eclass, and I noticed the following
code inside the eclass:
retval=$?
# Now kill Xvfb
kill $(cat /tmp/.X${XDISPLAY}-lock)
else
debug-print ${FUNCNAME}: attaching to running X display
# Normal make if we can connect to an X display
debug-print ${FUNCNAME}: ${VIRTUALX_COMMAND} \$@\
${VIRTUALX_COMMAND} $@
retval=$?
fi
# die if our command failed
[[ $? -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed.
Shouldn't that last line look more like this (notice $retval instead of $?):
[[ $retval -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed.
What do you think?
Ack to both what you said and what Michal said. Fixed in cvs :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk18f18ACgkQHB6c3gNBRYfoMACfYiOyC7nJlp/AI0gUE37KBVEL
dboAnRkahB1np882D/b7R80vGU9uzXky
=DFzF
-END PGP SIGNATURE-
[gentoo-dev] virtualx eclass possible issue
One of my ebuilds is using virtualx eclass, and I noticed the following
code inside the eclass:
retval=$?
# Now kill Xvfb
kill $(cat /tmp/.X${XDISPLAY}-lock)
else
debug-print ${FUNCNAME}: attaching to running X display
# Normal make if we can connect to an X display
debug-print ${FUNCNAME}: ${VIRTUALX_COMMAND} \$@\
${VIRTUALX_COMMAND} $@
retval=$?
fi
# die if our command failed
[[ $? -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed.
Shouldn't that last line look more like this (notice $retval instead of $?):
[[ $retval -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed.
What do you think?
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] virtualx eclass possible issue
On Sat, 12 Mar 2011 11:37:28 +0100
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
Shouldn't that last line look more like this (notice $retval instead
of $?):
[[ $retval -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND}
failed.
What do you think?
I'd say even '${VIRTUALX_COMMAND}'.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote:
Doug Goldstein wrote:
Doug Goldstein wrote:
While the rule of thumb has been if an eclass needs something it should
provide it's own depends. However the virtualx eclass needs to be
different simply because in some cases it's only uses for tests (this is
it's most common usage in the whole) tree. When it's used for tests
pulling in the xorg-server the most ideal situation would be if
xorg-server was only pulled in on USE=test because currently for anyone
emerging an app that uses GTK+ they have a weird situation in the fact
that all of GTK+'s depends that have USE=X use it to mean libX11 (as do
most usages of the X USE flag), however GTK+ itself due to it's usage of
the virtualx eclass pulls in xorg-server when USE=X, which is only used
for tests. This results in a confusing experience for users looking to
built a headless machine.
It'd be a lot more consistent if ebuilds provided a USE flag or directly
depended on the xorg-server and then used the functions in the eclass.
So in summary, those are the changes I plan on making very shortly. If
someone's got some input, please speak up.
Alright... after talking to Diego, Dave, and Remi the final result that
I've come up with is the following:
VIRTUALX_CONDITIONAL_USE=test
inherit virtualx
That'll result in virtualx adding the following:
DEPEND=test? ( x11-base/xorg-server x11-apps/xhost )
if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds
initially) the default will be X. Which means the default is the same
as what we've got today. If it's set to an empty string, it'll always be
required. Otherwise, it will use the supplied USE flag.
Turns out this situation breaks down when multiple USE flags are
required/used. One suggestion is to allow for that via:
VIRTUALX_CONDITIONAL_USE=test X
but needs someone to write some elegant shell to make that expansion
happen. Also, it'll happen in the global scope when the data is cached
so a little ugh on that part.
Huh?
VIRTUALX_DEPS=insert eclass needed atoms here
for flag in ${VIRTUALX_CONDITIONAL_USE}; do
DEPEND=${DEPEND} ${flag}? ( ${VIRTUALX_DEPS )
done
Am I missing something here?
The ebuild itself can then check if both need to be enabled etc.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Alright... after talking to Diego, Dave, and Remi the final result that I've come up with is the following: VIRTUALX_CONDITIONAL_USE=test inherit virtualx That'll result in virtualx adding the following: DEPEND=test? ( x11-base/xorg-server x11-apps/xhost ) if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds initially) the default will be X. Which means the default is the same as what we've got today. If it's set to an empty string, it'll always be required. Otherwise, it will use the supplied USE flag. Turns out this situation breaks down when multiple USE flags are required/used. One suggestion is to allow for that via: VIRTUALX_CONDITIONAL_USE=test X but needs someone to write some elegant shell to make that expansion happen. Also, it'll happen in the global scope when the data is cached so a little ugh on that part. The last fall back of course is to go to just defining VIRTUALX_DEPS and letting each ebuild USE it how it needs to use it. Feedback, comments, etc are appreciated. -- Doug Goldstein
[gentoo-dev] virtualx eclass
While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. -- Doug Goldstein
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Dave Leverton brings up a better suggestion. Providing VIRTUALX_DEPS and having the ebuild just toss that into it's depends as needed.
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Alright... after talking to Diego, Dave, and Remi the final result that I've come up with is the following: VIRTUALX_CONDITIONAL_USE=test inherit virtualx That'll result in virtualx adding the following: DEPEND=test? ( x11-base/xorg-server x11-apps/xhost ) if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds initially) the default will be X. Which means the default is the same as what we've got today. If it's set to an empty string, it'll always be required. Otherwise, it will use the supplied USE flag. -- Doug Goldstein
Re: [gentoo-dev] virtualx eclass
On 11:35 Thu 16 Oct , Doug Goldstein wrote: Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Alright... after talking to Diego, Dave, and Remi the final result that I've come up with is the following: VIRTUALX_CONDITIONAL_USE=test inherit virtualx That'll result in virtualx adding the following: DEPEND=test? ( x11-base/xorg-server x11-apps/xhost ) if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds initially) the default will be X. Which means the default is the same as what we've got today. If it's set to an empty string, it'll always be required. Otherwise, it will use the supplied USE flag. I'm not sure whether this would work, but one idea would be to handle dependencies depending on what's in IUSE of the ebuild inheriting. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgphn3ksNxYpD.pgp Description: PGP signature
Re: [gentoo-dev] virtualx eclass
On Thursday 16 October 2008 23:54:32 Donnie Berkholz wrote: I'm not sure whether this would work, but one idea would be to handle dependencies depending on what's in IUSE of the ebuild inheriting. That would require ebuilds to set IUSE before inheriting the eclass. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
