Re: [gentoo-dev] Clarify the as-is license?
On Sun, 23 Sep 2012, Rich Freeman wrote: - net-misc/ntp: as-is looks fine as main license, although some parts of the code are under different licenses like GPL (but I haven't checked in detail what gets installed). Uh, if we're distributing the sources, and they contain GPL content, then the only valid answer is GPL, Unfortunately, it's not clear from our documentation if the LICENSE variable applies to the source tarball or to the files that the package installs on the user's system. I tend to interpret it in the latter sense. To illustrate why, let's look at sci-visualization/gnuplot-4.6.0 as an example: LICENSE=gnuplot GPL-2 bitmap? ( free-noncomm ) The bulk of the package is free software, distributed under the gnuplot license or the GPL-2. However, there's an additional notice with a no-sale clause in a single source file (src/bitmap.c). If LICENSE applies to installed files, than we can disable the functionality via USE=-bitmap and we're done. However, if we say that LICENSE covers the source tarball, then we either need to change it to an unconditional gnuplot GPL-2 free-noncomm, which has the consequence that gnuplot is no longer installable for users who have ACCEPT_LICENSE=-* @FREE. Or, we must no longer distribute pristine source from upstream, but repack them into a new tarball with bitmap.c removed. This would have to be done for every release, which isn't feasible. Similar reasoning applies to the various Linux kernel packages that have LICENSE=GPL-2 !deblob? ( freedist ). or nomirror. That's a different issue. In the case of RESTRICT=mirror it is clear that it applies to the sources that we distribute. Ulrich
Re: [gentoo-dev] Clarify the as-is license?
On Mon, Sep 24, 2012 at 3:02 AM, Ulrich Mueller u...@gentoo.org wrote: Unfortunately, it's not clear from our documentation if the LICENSE variable applies to the source tarball or to the files that the package installs on the user's system. Hmm, if these aren't the same, then more likely than not something is wrong, but perhaps we'll have to confront this issue at some point. I tend to interpret it in the latter sense. To illustrate why, let's look at sci-visualization/gnuplot-4.6.0 as an example: LICENSE=gnuplot GPL-2 bitmap? ( free-noncomm ) The bulk of the package is free software, distributed under the gnuplot license or the GPL-2. However, there's an additional notice with a no-sale clause in a single source file (src/bitmap.c). If LICENSE applies to installed files, than we can disable the functionality via USE=-bitmap and we're done. I guess we can get away with redistributing the source files each under their respective license, since there is no derived work at this point. However, any binaries built from such a thing would not be redistributable. None of those licenses are GPL-compatible. However, if we say that LICENSE covers the source tarball, then we either need to change it to an unconditional gnuplot GPL-2 free-noncomm, which has the consequence that gnuplot is no longer installable for users who have ACCEPT_LICENSE=-* @FREE. Here is the thing - suppose somebody runs a Gentoo mirror but has ads on their page and is a commercial organization. They can't even MIRROR that source legally because of the presence of that one file, unless its license allows for-profit redistribution of the source. Or, we must no longer distribute pristine source from upstream, but repack them into a new tarball with bitmap.c removed. This would have to be done for every release, which isn't feasible. Not necessarily the end of the world to be honest - how many things do we have in the tree for which upstream only has an scm and no source tarballs, so we have to roll our own on every release anyway due to the prohibition on live scm packages being unmasked? Similar reasoning applies to the various Linux kernel packages that have LICENSE=GPL-2 !deblob? ( freedist ). or nomirror. That's a different issue. In the case of RESTRICT=mirror it is clear that it applies to the sources that we distribute. I think the key is to make sure that the sources at least can be distributed without getting anybody into trouble. If so we don't need to restrict them. However, I don't think the final thing can be @FREE - it isn't binary redistributable as the final built code isn't licensed at all. We should point this out somehow. Rich
Re: [gentoo-dev] Clarify the as-is license?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/09/12 08:10 AM, hasufell wrote: On 09/23/2012 02:04 PM, Ulrich Mueller wrote: If we really decide to move things to a new license file, then I'd rather avoid the name as-is because it is partly the reason for the confusion. I agree on that. I saw it more than once that people use as-is for the license, just because there is an as is clause. What about having some snippet licenses that could be amalgomated as-needed for a package? IE: - -'as-is' would be the generic as-is statement - -'free-non-commercial' would be a free/unrestricted for non-commercial use statement - -'free-unrestricted' would be a statement of more or less public domain - -..etc... ..and then ebuilds can include the particular phrases that apply? ie, LICENSE=(as-is free-non-commercial) , essentially an 'assemble-your-own-license' from the snippets. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBgWagACgkQ2ugaI38ACPDY2wD9EnVU9c1E6xW7o2pOhJbj8ocW KHdXq0qiK156X4RFPCEBAJ4aNaEsF0cy615RLOjFm1r/vqNRcX5t91g+1psaNbiC =gwvg -END PGP SIGNATURE-
Re: [gentoo-dev] Clarify the as-is license?
On Mon, 24 Sep 2012, Rich Freeman wrote: I tend to interpret it in the latter sense. To illustrate why, let's look at sci-visualization/gnuplot-4.6.0 as an example: LICENSE=gnuplot GPL-2 bitmap? ( free-noncomm ) The bulk of the package is free software, distributed under the gnuplot license or the GPL-2. However, there's an additional notice with a no-sale clause in a single source file (src/bitmap.c). If LICENSE applies to installed files, than we can disable the functionality via USE=-bitmap and we're done. I guess we can get away with redistributing the source files each under their respective license, since there is no derived work at this point. However, any binaries built from such a thing would not be redistributable. None of those licenses are GPL-compatible. This is not a problem here. Gnuplot itself is licensed under the gnuplot license. The GPL licensed parts (e.g. Gnuplot mode for Emacs) are not linked with it but installed separately. The GPL doesn't forbid mere accumulation of things, so redistribution of the binary isn't an issue. [...] Not necessarily the end of the world to be honest - how many things do we have in the tree for which upstream only has an scm and no source tarballs, so we have to roll our own on every release anyway due to the prohibition on live scm packages being unmasked? Too many already, so we shouldn't add more when it's not necessary. Ulrich
Re: [gentoo-dev] Clarify the as-is license?
Ian Stakenvicius schrieb: IE: - -'as-is' would be the generic as-is statement - -'free-non-commercial' would be a free/unrestricted for non-commercial use statement - -'free-unrestricted' would be a statement of more or less public domain - -..etc... Why not directly use the FSF freedoms: The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). The freedom to redistribute copies so you can help your neighbor (freedom 2). The freedom to distribute copies of your modified versions to others (freedom 3). I think when combined appropriately, they nicely cover most of the cases of current as-is packages. ..and then ebuilds can include the particular phrases that apply? ie, LICENSE=(as-is free-non-commercial) , essentially an 'assemble-your-own-license' from the snippets. We would maybe have to find a different operator for license concatenation. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Clarify the as-is license?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/09/12 06:46 AM, Rich Freeman wrote:
On Mon, Sep 24, 2012 at 3:02 AM, Ulrich Mueller u...@gentoo.org
wrote:
Unfortunately, it's not clear from our documentation if the
LICENSE variable applies to the source tarball or to the files
that the package installs on the user's system.
Hmm, if these aren't the same, then more likely than not something
is wrong, but perhaps we'll have to confront this issue at some
point.
After the debate on IRC that spawn the request to add GPL-2 to LICENSE
for all the packages that install init scripts, I would expect that
the LICENSE applies primarily to the installed-image but when
necessary/different would also apply to an upstream distfile and its
contents. However, it is safe to exclude licenses of patches,
contributed files, etc. that are stored in ${FILESDIR}.
Is this interpretation correct?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBgXgoACgkQ2ugaI38ACPCxkgEAqydntc6k6YcC3lce2aaxMUSy
csX3CfTcsKA04TDeZskA/30v+V6G1JXaTUocI4BszvzYqUvt6b+go3uJI+I0LUnn
=8B/x
-END PGP SIGNATURE-
Re: [gentoo-dev] Clarify the as-is license?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/09/12 09:15 AM, Chí-Thanh Christopher Nguyễn wrote: Ian Stakenvicius schrieb: IE: - -'as-is' would be the generic as-is statement - -'free-non-commercial' would be a free/unrestricted for non-commercial use statement - -'free-unrestricted' would be a statement of more or less public domain - -..etc... Why not directly use the FSF freedoms: The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). The freedom to redistribute copies so you can help your neighbor (freedom 2). The freedom to distribute copies of your modified versions to others (freedom 3). I think when combined appropriately, they nicely cover most of the cases of current as-is packages. Yep, it would. Still, however, need the standard Provided 'AS-IS' with no disclaimer of warranty blah blah statement which afaik would not be included in any way in the FSF list (unless one of those freedoms would actually be 'The freedom of the author to have no repercussions whatsoever brought against them as a result of the program's use or mis-use', of course) ..and then ebuilds can include the particular phrases that apply? ie, LICENSE=(as-is free-non-commercial) , essentially an 'assemble-your-own-license' from the snippets. We would maybe have to find a different operator for license concatenation. I don't know if an operator would actually be necessary; i just figured ()-wrapping would asthetically differentiate these from additional licenses that might be tagged on (ie if part of the package was also GPL-2) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBgX0sACgkQ2ugaI38ACPBdtwD9HVqCMlBKh6dNvylp+6bC5PMx GezaE4DdeEU7n86E4JcBAJ+GG+zQ4MkMAj9cjP1qBXD3MkpzocjNz+u4OlRI1AU4 =waBv -END PGP SIGNATURE-
Re: [gentoo-dev] Clarify the as-is license?
On Mon, 24 Sep 2012, Chí-Thanh Christopher Nguyễn wrote: Ian Stakenvicius schrieb: IE: - -'as-is' would be the generic as-is statement - -'free-non-commercial' would be a free/unrestricted for non-commercial use statement - -'free-unrestricted' would be a statement of more or less public domain - -..etc... Why not directly use the FSF freedoms: The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). The freedom to redistribute copies so you can help your neighbor (freedom 2). The freedom to distribute copies of your modified versions to others (freedom 3). I think when combined appropriately, they nicely cover most of the cases of current as-is packages. This has been suggested before, but for license groups. The problem is that the four freedoms are good criteria for Free Software, but there's no good mapping to the elements of most non-free licenses. Try it yourself for a few concrete cases (of non-free licenses in our tree), and you'll see what I mean. Ulrich
Re: [gentoo-dev] [RFC] Multiple ABI support through package appending/partial removal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23/09/12 06:09 PM, Michał Górny wrote:
Hello,
Since my previous idea of DYNAMIC_SLOTS proved too complex to
design and implement, I would like to offer an another idea, based
partially on what Ciaran mentioned. Before I start getting into
details, I'd like to know your opinions, and what possible problems
am I missing. To keep it clean, I will focus on Python ABIs but
other languages and multilib could be handled in a similar manner.
The problem ===
Right now, building packages for multiple Python ABIs is done
using USE_EXPAND-based useflags. This is a working solution but it
requires rebuilding the package for all ABIs whenever the chosen
ABI list changes.
While it may be not that important for most of the Python packages,
it becomes such when it comes to things like boost or -- if we'd
extend that to multilib -- say, llvm. In that case, whenever a
newly-installed package requests a specific ABI, user has to spend
twice as much time to rebuild the same version.
The general idea
While not getting too deep into ebuild syntax, the core part of the
idea is to mark some of the USE_EXPAND variables 'special'. In this
particular example, such a special flag group would be
'PYTHON_TARGETS'.
Now, let's consider user installs a new package with one
python_targets_python2_7 enabled. The package is built and
installed like usual but aside to regular vdb files an additional
file is introduced, listing all the installed files as 'belonging'
to python_targets_python2_7.
If user enables python_targets_python3_2 on the same package, the
PM doesn't trigger a full rebuild. Instead, it builds the package
with the new flag being the only flag in PYTHON_TARGETS. The new
files are installed over the installed package (and added to
CONTENTS in vdb), and the files in install image are listed in vdb
as 'belonging' to python_targets_python3_2.
Whenever files from two ABIs collide, package manager either
replaces the installed files if the 'new' ABI is considered
'better' than the old one or preserves it. This follows the current
behavior when multiple ABIs are built, and later builds overwrite
files from earlier ones.
[ Snip! ]
This -could- be done, for testing purposes, entirely within an eclass,
if you'd like. Generate the file lists for each target during the
targets-specific src_install phase and install 'em to
/usr/share/${PN}-${PVR} , and then read 'em back at src_prepare if the
package has already been installed. Worth a shot to see if this is
really doable..
For testing purposes (or maybe as an overall solution) src_install
could copy back all the currently-installed files from ${EROOT} into
${D} for the targets that are being kept.. (probably prior to the
'real' src_install functions so updated files overwrite the old ones)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBgaZEACgkQ2ugaI38ACPBi9gD/TjXQbsIFrtVpX/9wewNF2tnV
aITgy/JOR67EprpeMucBAKUzGtbDu/8fU4B8jXiy+4VODj6X1T/CqpK7EamzLaV3
=rOcp
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 12:17:58 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that. Can you guarantee that the build system won't modify any file in the source tree? And AFAIR we don't have any COW filesystems in Gentoo. So it's back to optimized solution vs bad, universal solution. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 19:32:14 +0200 Michał Górny mgo...@gentoo.org wrote: On Mon, 24 Sep 2012 12:17:58 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that. Can you guarantee that the build system won't modify any file in the source tree? You can add it as a requirement. Your eclass implicitly requires it anyway. So it's back to optimized solution vs bad, universal solution. or rather writing multilib support for every package vs. using what ebuilds already offer you: a common API for building every package.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 14:53:27 -0300 Alexis Ballier aball...@gentoo.org wrote: On Mon, 24 Sep 2012 19:32:14 +0200 Michał Górny mgo...@gentoo.org wrote: On Mon, 24 Sep 2012 12:17:58 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that. Can you guarantee that the build system won't modify any file in the source tree? You can add it as a requirement. Your eclass implicitly requires it anyway. So it's back to optimized solution vs bad, universal solution. or rather writing multilib support for every package vs. using what ebuilds already offer you: a common API for building every package. Ebuilds don't offer me anything if I have to rewrite phase functions anyway... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 20:12:40 +0200 Michał Górny mgo...@gentoo.org wrote: to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? [...] Ebuilds don't offer me anything if I have to rewrite phase functions anyway... what, in the above quote, makes you think you need to rewrite anything ?
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 16:16:53 -0300 Alexis Ballier aball...@gentoo.org wrote: On Mon, 24 Sep 2012 20:12:40 +0200 Michał Górny mgo...@gentoo.org wrote: to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? [...] Ebuilds don't offer me anything if I have to rewrite phase functions anyway... what, in the above quote, makes you think you need to rewrite anything ? 1. If ebuild has phase functions, they override the eclass. 2. If eclass exports phase functions, they have no way of calling 'previous' eclass phase functions. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] [PATCH] python-r1: introduce PYTHON executable getter.
A semi-replacement for _python-distutils-ng_very_long_name...
Unlike the forementioned function, it returns just the binary name
and not the complete path. Thus, the executable rewrite in p-d-ng has
been changed to use #!/usr/bin/env.
---
gx86/eclass/python-distutils-ng.eclass | 28
gx86/eclass/python-r1.eclass | 20
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index 34717aa..33d183c 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -54,26 +54,6 @@ EXPORT_FUNCTIONS src_prepare src_configure src_compile
src_test src_install
DEPEND=${DEPEND} !sys-apps/portage-2.1.10.58
-# @FUNCTION: _python-distutils-ng_get_binary_for_implementation
-# @USAGE: implementation
-# @RETURN: Full path to Python binary for given implementation.
-# @DESCRIPTION:
-# This function returns full path for Python binary for given implementation.
-#
-# Binary returned by this function should be used instead of simply calling
-# `python'.
-_python-distutils-ng_get_binary_for_implementation() {
- local impl=${1/_/.}
- case ${impl} in
- python?.?|jython?.?)
- echo /usr/bin/${impl} ;;
- pypy?.?)
- echo /usr/bin/pypy-c${impl: -3} ;;
- *)
- die Unsupported implementation: ${1} ;;
- esac
-}
-
RDEPEND=${PYTHON_DEPS}
DEPEND=${PYTHON_DEPS}
@@ -90,7 +70,7 @@ _python-distutils-ng_run_for_impl() {
local command=${2}
local S=${WORKDIR}/impl_${impl}/${_PACKAGE_SPECIFIC_S}
- PYTHON=$(_python-distutils-ng_get_binary_for_implementation ${impl})
+ PYTHON=$(python_get_PYTHON ${impl})
EPYTHON=${impl/_/.}
einfo Running ${command} in ${S} for ${impl}
@@ -147,10 +127,10 @@ python-distutils-ng_rewrite_hashbang() {
[[ -n ${1} ]] || die Missing file name
[[ -n ${2} ]] || die Missing implementation
local file_name=${1}
- local binary=$(_python-distutils-ng_get_binary_for_implementation
${2})
+ local binary=$(python_get_PYTHON ${2})
[[ $(head -n 1 ${file_name}) == '#!'*(python|jython|pypy-c)* ]] || \
die Missing or invalid #! line in ${file_name}
- sed -i -e 1c#!${binary} ${file_name} || die
+ sed -i -e 1c#!/usr/bin/env ${binary} ${file_name} || die
}
# @FUNCTION: python-distutils-ng_redoscript
@@ -253,7 +233,7 @@ python-distutils-ng_src_prepare() {
# Try to run binary for each implementation:
for impl in ${PYTHON_COMPAT[@]}; do
use python_targets_${impl} ${PYTHON_COMPAT[@]} || continue
- $(_python-distutils-ng_get_binary_for_implementation ${impl})
\
+ $(python_get_PYTHON ${impl}) \
-c import sys || die
done
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 68b5c38..4c4d69d 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -118,3 +118,23 @@ _python_set_globals() {
done
}
_python_set_globals
+
+# @FUNCTION: python_get_PYTHON
+# @USAGE: impl
+# @DESCRIPTION:
+# Get the Python executable name for the given implementation.
+python_get_PYTHON() {
+ local impl=${1/_/.}
+
+ case ${impl} in
+ python*|jython*)
+ echo ${impl}
+ ;;
+ pypy*)
+ echo pypy-c${impl#pypy}
+ ;;
+ *)
+ die Invalid argument to python_get_PYTHON: ${1}
+ ;;
+ esac
+}
--
1.7.12
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 22:47:33 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 16:16:53 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 20:12:40 +0200
Michał Górny mgo...@gentoo.org wrote:
to some extent, can't you do the same by unpacking
twice to different $S and calling
src_prepare/compile/install instead of their
autotools-utils counterpart with tweaked $S so that
it works with almost every ebuild ?
[...]
Ebuilds don't offer me anything if I have to rewrite phase
functions anyway...
what, in the above quote, makes you think you need to rewrite
anything ?
1. If ebuild has phase functions, they override the eclass.
2. If eclass exports phase functions, they have no way of calling
'previous' eclass phase functions.
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
then, in a future EAPI, let the PM call src_multilib_compile instead
of src_compile if multilib is requested.
this needs very minimal PM/EAPI support, leaves the multilib code
into eclasses, leaves multilib opt-in so that noarch or packages not
installing a lib dont need to care, and also leaves room for cleaner
more specific eclasses like yours
[gentoo-dev] [PATCH 1/2] p-d-ng: split out default impl selection logic.
Move the logic out of doscript() to make it reusable. Also, use
_PYTHON_ALL_IMPLS[@] instead of hardcoding the preference list.
---
gx86/eclass/python-distutils-ng.eclass | 38 +-
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index 33d183c..ab13ffc 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -160,6 +160,29 @@ python-distutils-ng_doscript() {
python-distutils-ng_newscript ${1} $(basename ${1}) ${2}
}
+# Get the preferred implementation for the symlink.
+_python-distutils-ng_get_best_impl() {
+ local defimpl=${PYTHON_DEFAULT_IMPLEMENTATION}
+
+ if [[ ${defimpl} ]]; then
+ if use ${defimpl}; then
+ echo ${defimpl}
+ else
+ die default implementation ${defimpl} not enabled.
+ fi
+ else
+ local impl
+ for impl in ${_PYTHON_ALL_IMPLS[@]}; do
+ if use python_targets_${impl}; then
+ echo ${impl}
+ return
+ fi
+ done
+ fi
+
+ die unable to find a default Python implementation.
+}
+
# @FUNCTION: python-distutils-ng_newscript
# @USAGE: script_file_name new_file_name [destination_directory]
# @DESCRIPTION:
@@ -184,7 +207,7 @@ python-distutils-ng_newscript() {
[[ -n ${2} ]] || die Missing destination file name
local source_file=${1}
local destination_file=${2}
- local default_impl=${PYTHON_DEFAULT_IMPLEMENTATION}
+ local default_impl=$(_python-distutils-ng_get_best_impl)
local enabled_impls=0
local destination_directory=/usr/bin
[[ -n ${3} ]] destination_directory=${3}
@@ -194,19 +217,6 @@ python-distutils-ng_newscript() {
enabled_impls=$((enabled_impls + 1))
done
- if [[ -z ${default_impl} ]]; then
- for impl in python{2_7,2_6,2_5,3_2,3_1} pypy{1_9,1_8,1_7}
jython2_5; do
- use python_targets_${impl} || continue
- default_impl=${impl}
- break
- done
- else
- use python_targets_${default_impl} || \
- die default implementation ${default_impl} not enabled
- fi
-
- [[ -n ${default_impl} ]] || die Could not select default
implementation
-
dodir ${destination_directory}
insinto ${destination_directory}
if [[ ${enabled_impls} = 1 ]]; then
--
1.7.12
[gentoo-dev] [PATCH 2/2] p-d-ng: use distutils-made scripts instead of 'redoing' them.
Instead of 'redoing' the installed script, just rename the ones
installed by distutils in each phase.
This also changes suffixes from -pythonX_Y to -pythonX.Y for no good
reason.
---
gx86/eclass/python-distutils-ng.eclass | 39 +++---
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index ab13ffc..b478277 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -292,25 +292,48 @@ python-distutils-ng_src_test() {
fi
}
-# Phase function: src_install
-python-distutils-ng_src_install() {
+# A wrapper necessary to 'redo' scripts.
+_python-distutils-ng_install_wrapper() {
if type python_install /dev/null; then
- _python-distutils-ng_run_for_each_impl python_install
+ python_install ${@}
else
- _python-distutils-ng_run_for_each_impl \
- _python-distutils-ng_default_distutils_install
+ _python-distutils-ng_default_distutils_install ${@}
fi
+ if [[ -z ${PYTHON_DISABLE_SCRIPT_REDOS} ]]; then
+ local f
+ # XXX: change this if we ever allow directories in bin/sbin
+ for f in ${D}/{,usr/}{,s}bin/*; do
+ if [[ -x ${f} ]]; then
+ if [[ $(head -n 1 ${f}) == '#!'*${PYTHON}*
]]
+ then
+ mv ${f} ${f}-${EPYTHON} || die
+ fi
+ fi
+ done
+ fi
+}
+
+# Phase function: src_install
+python-distutils-ng_src_install() {
+ _python-distutils-ng_run_for_each_impl \
+ _python-distutils-ng_install_wrapper
+
if type python_install_all /dev/null; then
einfo Running python_install_all in ${S} for all
pushd ${S} /dev/null
python_install_all
popd /dev/null
fi
-
if [[ -z ${PYTHON_DISABLE_SCRIPT_REDOS} ]]; then
- for script_file in $(find ${D}{,usr/}{,s}bin/ -type f
-executable 2 /dev/null); do
- python-distutils-ng_redoscript /${script_file#${D}}
+ local best_impl=$(_python-distutils-ng_get_best_impl)
+ local f
+
+ # XXX: change this if we ever allow directories in bin/sbin
+ for f in ${D}/{,usr/}{,s}bin/*-${best_impl/_/.}; do
+ if [[ -x ${f} ]]; then
+ ln -s ${f##*/} ${f%-*} || die
+ fi
done
fi
}
--
1.7.12
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be called
from the phase function to call the phase function...?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Tue, 25 Sep 2012 00:10:21 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you:
call directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be
called from the phase function to call the phase function...?
Read again. Esp. the part you deleted.
I never said it should do this, on purpose...
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, Sep 24, 2012 at 3:22 PM, Alexis Ballier aball...@gentoo.org wrote:
On Tue, 25 Sep 2012 00:10:21 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you:
call directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be
called from the phase function to call the phase function...?
Read again. Esp. the part you deleted.
I never said it should do this, on purpose...
I'm especially confused by what your point is. I can't see how your
snippet could ever work, and you're being evasive about answering
that.
[gentoo-portage-dev] blech... (multijob/multiprocessing work-around for cygwin)
On cygwin, there is a problem with bi-directional pipe support in bash.
I used to solve this with an ugly reversion in portage and an
ultra-simple stubbification patch for multiprocessing.eclass (both
serialized everything).
However, this really sucked for numerous reasons, including the obvious
one: it makes stuff slow as hell.
So I've reworked everything to use uni-directional named pipes.
In portage I have:
diff --git a/bin/helper-functions.sh b/bin/helper-functions.sh
index c7400fa..87f3120 100644
--- a/bin/helper-functions.sh
+++ b/bin/helper-functions.sh
@@ -7,6 +7,36 @@
source ${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}/isolated-functions.sh
+# try real hard to figure out if this is a cygwin host; cache results.
+this_host_is_cygwin() {
+ if [[ -n ${_this_host_is_cygwin} ]] ; then
+ return $_this_host_is_cygwin
+ fi
+ [[ -x ${EPREFIX}/usr/bin/uname ]] \
+ [[ $( ${EPREFIX}/usr/bin/uname -o 2/dev/null ) == Cygwin* ]]
\
+ export _this_host_is_cygwin=0 return 0
+ [[ -x /usr/bin/uname ]] \
+ [[ $( /usr/bin/uname -o 2/dev/null ) == Cygwin* ]] \
+ export _this_host_is_cygwin=0 return 0
+ [[ -x /bin/uname ]] \
+ [[ $( /bin/uname -o 2/dev/null ) == Cygwin* ]] \
+ export _this_host_is_cygwin=0 return 0
+ # hail-mary before we resort to envvars
+ [[ $( uname -o 2/dev/null ) == Cygwin* ]] \
+ export _this_host_is_cygwin=0 return 0
+
+ [[ -n ${CHOST} ]] \
+ [[ ${CHOST} == *-cygwin* ]] \
+ export _this_host_is_cygwin=0 return 0
+ [[ -n ${CTARGET} ]] \
+ [[ ${CTARGET} == *-cygwin* ]] \
+ export _this_host_is_cygwin=0 return 0
+
+ # either it ain't cygwin or something is very broken.
+ export _this_host_is_cygwin=1
+ return 1
+}
+
#
# API functions for doing parallel processing
#
@@ -19,25 +49,51 @@ numjobs() {
multijob_init() {
# Setup a pipe for children to write their pids to when they finish.
- mj_control_pipe=$(mktemp -t multijob.XX)
- rm ${mj_control_pipe}
- mkfifo ${mj_control_pipe}
- redirect_alloc_fd mj_control_fd ${mj_control_pipe}
+ export mj_control_pipe=$(mktemp -t multijob.XX)
rm -f ${mj_control_pipe}
+ mkfifo ${mj_control_pipe}
+
+ if ! this_host_is_cygwin ; then
+ redirect_alloc_fd mj_control_fd ${mj_control_pipe}
+ rm -f ${mj_control_pipe}
+ fi
# See how many children we can fork based on the user's settings.
mj_max_jobs=$(numjobs)
mj_num_jobs=0
}
+# make sure someone called multijob_init
+multijob_assert() {
+ if this_host_is_cygwin ; then
+ [[ -z ${mj_control_pipe} ]] \
+ die multijob initialization required
+ [[ $( file -b ${mj_control_pipe} ) != fifo* ]] \
+ die multijob fifo gone
+ else
+ [[ -z ${mj_control_fd} ]] \
+ die multijob initialization required
+ fi
+}
+
multijob_child_init() {
- trap 'echo ${BASHPID} $? '${mj_control_fd} EXIT
+ multijob_assert
+ if this_host_is_cygwin ; then
+ trap 'echo ${BASHPID} $? '${mj_control_pipe} EXIT
+ else
+ trap 'echo ${BASHPID} $? '${mj_control_fd} EXIT
+ fi
trap 'exit 1' INT TERM
}
multijob_finish_one() {
local pid ret
- read -r -u ${mj_control_fd} pid ret
+ multijob_assert
+ if this_host_is_cygwin ; then
+ read -r pid ret ${mj_control_pipe}
+ else
+ read -r -u ${mj_control_fd} pid ret
+ fi
: $(( --mj_num_jobs ))
return ${ret}
}
@@ -70,6 +126,9 @@ multijob_post_fork() {
redirect_alloc_fd() {
local var=$1 file=$2 redir=${3:-}
+ [[ ${redir} == ]] this_host_is_cygwin \
+ die Cygwin bash has broken bidirectional redirection
support.
+
if [[ $(( (BASH_VERSINFO[0] 8) + BASH_VERSINFO[1] )) -ge $(( (4
8) + 1 )) ]] ; then
# Newer bash provides this functionality.
eval exec {${var}}${redir}'${file}'
--
(Here's hoping Thunderbird didn't reflow the above; apologies in advance
if it did)
In multiprocessing.eclass, I do something fairly similar, also relying
on named pipes rather than file-descriptor cloning.
I was wondering if anyone in the know could comment on how correct or
incorrect the above actually is? For example, is either portage
multijob or mutliprocessing.eclass expected to work if someone nests
multijob_init's (because I'm pretty sure mine won't -- FTR, this seems
pretty naughty, given that both get their parallelism defaults from
MAKEOPTS)?
Finally, to be clear, I'm not wanting this to go in to git or
anything... at least, certainly not
[gentoo-portage-dev] [PATCH 2/2] Document behaviour of --root-deps for EAPI 6+ in emerge(1)
--- man/emerge.1 | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/man/emerge.1 b/man/emerge.1 index ea6409c..5861bb6 100644 --- a/man/emerge.1 +++ b/man/emerge.1 @@ -711,10 +711,11 @@ of packages for \fBROOT\fR. This option is only meaningful when used together with \fBROOT\fR and it should not be enabled under normal circumstances! -For currently supported \fBEAPI\fR values, the build-time dependencies are -specified in the \fBDEPEND\fR variable. -However, behavior may change for new \fBEAPI\fRs when related extensions are -added in the future. +Affects \fBEAPI 5\fR and earlier ebuilds only. +Experimental \fBEAPI 5-hdepend\fR and later provide \fBHDEPEND\fR as a new +means to adjust installation into \fI/\fR and \fBROOT\fR. +If \fBEAPI 5\fR and earlier ebuilds are built in the same \fBemerge\fR run as +\fBEAPI 5-hdepend\fR and later ebuilds, this option affects only the former. .TP .BR \-\-select [ y | n ] Add specified packages to the world set (inverse of -- 1.7.12
[gentoo-portage-dev] [PATCH 1/2] Document HDEPEND in ebuild(5)
--- man/ebuild.5 | 46 ++ 1 file changed, 46 insertions(+) diff --git a/man/ebuild.5 b/man/ebuild.5 index 5bb1afa..a15bf55 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -316,6 +316,36 @@ the user does not specify any of the previous choices. Note that if any of the packages listed are already merged, the package manager will use that to consider the dependency satisfied. +.SS Cross-compilation +Portage supports cross-compilation into a subdirectory specified by \fBROOT\fR. +.TP +.B Host +\fIHost\fR in this context means the platform hosting the build process, i.e. +what autotools calls CBUILD. +Its packages are contained in the root of the filesystem (\fI/\fR). +If \fBROOT\fR is \fI/\fR, all dependency types will be installed there. +Otherwise, starting from experimental \fBEAPI 5-hdepend\fR, only \fBHDEPEND\fR +is installed into \fI/\fR. +In \fBEAPI 5\fR and earlier, the behaviour is controlled by the +\fI\-\-root-deps\fR flag to \fBemerge\fR(1), defaulting to install only +\fBDEPEND\fR into the \fIhost\fR. +.TP +.B Target +\fITarget\fR refers to the platform that the package will later run on, i.e. +what autotools calls CHOST. +The directory housing this system is specified by \fBROOT\fR. +If it is different from \fI/\fR, i.e. \fIhost\fR and \fItarget\fR are not the +same, this variable contains the path to the directory housing the \fItarget\fR +system. +Starting from experimental \fBEAPI 5-hdepend\fR, \fBDEPEND\fR and \fBRDEPEND\fR +list the \fItarget\fR dependencies, i.e. those to be installed into \fBROOT\fR. +In \fBEAPI 5\fR and earlier, the \fBemerge\fR(1) flag \fI\-\-root-deps\fR +controlled what the package manager installed there, defaulting to only +\fBRDEPEND\fR. +.PP +See section \fBVARIABLES\fR for more information about the \fBDEPEND\fR, +\fBRDEPEND\fR and \fBHDEPEND\fR variables. + .SH VARIABLES .TP .B Usage Notes @@ -547,6 +577,11 @@ This should contain a list of all packages that are required for the program to compile (aka \fIbuildtime\fR dependencies). These are usually libraries and headers. +Starting from experimental \fBEAPI 5-hdepend\fR, tools should go into the +\fBHDEPEND\fR variable instead, as \fBDEPEND\fR will only be installed into the +\fItarget\fR system and hence cannot be executed in a cross\-compile setting. +(See section \fBCross\-compilation\fR for more information.) + You may use the syntax described above in the \fBDependencies\fR section. .TP .B RDEPEND @@ -559,6 +594,17 @@ implicitly set. You may use the syntax described above in the \fBDependencies\fR section. .TP +.B HDEPEND +This should contain a list of all packages that are required to be executable +during compilation of this program (aka \fIhost\fR buildtime dependencies). +These are usually tools, like interpreters or (cross\-)compilers. + +This variable is new in experimental \fBEAPI 5-hdepend\fR and will be installed +into the \fIhost\fR system. +(See section \fBCross-compilation\fR for more information.) + +You may use the syntax described above in the \fBDependencies\fR section. +.TP .B PDEPEND This should contain a list of all packages that should be merged after this one (aka \fIpost\fR merge dependencies), but which may be installed by the -- 1.7.12
[gentoo-portage-dev] Please review: manpage-hdepend
Hi! These patches document HDEPEND and incorporate the suggestions Zac gave on the gentoo-portage-dev mailinglist regarding EAPI 6 vs. EAPI 5-hdepend. Best regards, Dennis
Re: [gentoo-portage-dev] blech... (multijob/multiprocessing work-around for cygwin)
On 09/24/2012 03:25 AM, Gregory M. Turner wrote:
+# try real hard to figure out if this is a cygwin host; cache results.
+this_host_is_cygwin() {
+if [[ -n ${_this_host_is_cygwin} ]] ; then
+return $_this_host_is_cygwin
+fi
+[[ -x ${EPREFIX}/usr/bin/uname ]] \
+[[ $( ${EPREFIX}/usr/bin/uname -o 2/dev/null ) == Cygwin* ]] \
+export _this_host_is_cygwin=0 return 0
You could probably just assume that uname is in $PATH and remove all the
other tests.
multijob_finish_one() {
local pid ret
-read -r -u ${mj_control_fd} pid ret
+multijob_assert
+if this_host_is_cygwin ; then
+read -r pid ret ${mj_control_pipe}
+else
+read -r -u ${mj_control_fd} pid ret
+fi
: $(( --mj_num_jobs ))
return ${ret}
}
Since you re-open the pipe for each read, there's a race condition which
I've explained here:
http://permalink.gmane.org/gmane.linux.gentoo.devel/77528
--
Thanks,
Zac
Re: [gentoo-portage-dev] [PATCH] Implement host dependencies and targetroot USE flag
On Monday 24 September 2012 06:11:01 Ambroz Bizjak wrote:
case ${EAPI} in
But then, there are two other places in ebuild.sh using case EAPI and
they both look exactly like mine. Updated patch changes all of them.
WFM, thanks
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] blech... (multijob/multiprocessing work-around for cygwin)
On Monday 24 September 2012 06:25:35 Gregory M. Turner wrote:
On cygwin, there is a problem with bi-directional pipe support in bash.
I used to solve this with an ugly reversion in portage and an
ultra-simple stubbification patch for multiprocessing.eclass (both
serialized everything).
However, this really sucked for numerous reasons, including the obvious
one: it makes stuff slow as hell.
if cygwin sucks, it doesn't get parallel jobs. add stubs to the end of the
file to disable parallel support.
if is_cygwin ; then
numjobs() { return 1; }
multijob_init() { return 0; }
...etc...
fi
interleaving the cygwin logic otherwise makes it unmaintainable
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] blech... (multijob/multiprocessing work-around for cygwin)
On 9/24/2012 9:08 AM, Zac Medico wrote:
On 09/24/2012 03:25 AM, Gregory M. Turner wrote:
multijob_finish_one() {
local pid ret
-read -r -u ${mj_control_fd} pid ret
+multijob_assert
+if this_host_is_cygwin ; then
+read -r pid ret ${mj_control_pipe}
+else
+read -r -u ${mj_control_fd} pid ret
+fi
: $(( --mj_num_jobs ))
return ${ret}
}
Since you re-open the pipe for each read, there's a race condition which
I've explained here:
http://permalink.gmane.org/gmane.linux.gentoo.devel/77528
Gross, thanks for this pointer, Zac. Plenty of solutions one could
concoct, but no point dumping effort into this black-hole when I can
just wait for somebody else to get fed up and fix the underlying problem
for me :)
Guess it's back to stubs, for now.
-gmt
Re: [gentoo-portage-dev] [PATCH] Implement host dependencies and targetroot USE flag
On 09/24/2012 03:11 AM, Ambroz Bizjak wrote: --- bin/ebuild.sh| 34 +++-- pym/_emerge/depgraph.py | 57 +--- pym/_emerge/main.py | 1 - pym/portage/__init__.py | 4 +-- pym/portage/dbapi/bintree.py | 6 ++-- pym/portage/dbapi/porttree.py| 2 +- pym/portage/dbapi/vartree.py | 1 + pym/portage/eapi.py | 9 +- pym/portage/package/ebuild/config.py | 14 +++-- 9 files changed, 87 insertions(+), 41 deletions(-) Thanks, I've committed your patch: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=814e82f24afc221eee72f2b53a3fb7587605cbf9 I just made a few trivial changes, adding HDEPEND in more places that work with *DEPEND variables, and ordering variable lists in lexical order. -- Thanks, Zac
Re: [gentoo-portage-dev] Please review: manpage-hdepend
On 09/24/2012 05:16 AM, Dennis Schridde wrote: Hi! These patches document HDEPEND and incorporate the suggestions Zac gave on the gentoo-portage-dev mailinglist regarding EAPI 6 vs. EAPI 5-hdepend. Best regards, Dennis Thanks, I've applied your patches. I've also made some changes here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a2e36694d14cc895592b36ba812e55f5cfdd9923 -- Thanks, Zac
Re: [gentoo-portage-dev] Please review: manpage-hdepend
Hi! Am Montag, 24. September 2012, 14:04:10 schrieb Zac Medico: On 09/24/2012 05:16 AM, Dennis Schridde wrote: Thanks, I've applied your patches. I've also made some changes here: Tow comments: * I tried to use \fI for emphasis, cmdline flags and other minor things, and \fB for references to variables, sections, manpages, etc. (Re: \fBdo not\fR, \fBdo\fR) * Why did you drop defaulting to only \fBRDEPEND\fR from the Target subsection describing --root-deps? Was it wrong? I tried to give a quick overview over how cross-compilation is handled and what behaviour to expect. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Please review: manpage-hdepend
Am Montag, 24. September 2012, 23:18:59 schrieb Dennis Schridde: Am Montag, 24. September 2012, 14:04:10 schrieb Zac Medico: * I tried to use \fI for emphasis, cmdline flags and other minor things, and \fB for references to variables, sections, manpages, etc. (Re: \fBdo not\fR, \fBdo\fR) P.S: This seemed to be how sys-apps/man-pages and sys-apps/man-pages-posix do it. P.P.S: Thanks for applying the patches and especially for your comments and help with submitting them correctly. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Please review: manpage-hdepend
On 09/24/2012 02:18 PM, Dennis Schridde wrote: Hi! Am Montag, 24. September 2012, 14:04:10 schrieb Zac Medico: On 09/24/2012 05:16 AM, Dennis Schridde wrote: Thanks, I've applied your patches. I've also made some changes here: Tow comments: * I tried to use \fI for emphasis, cmdline flags and other minor things, and \fB for references to variables, sections, manpages, etc. (Re: \fBdo not\fR, \fBdo\fR) Okay, will change those to italics. * Why did you drop defaulting to only \fBRDEPEND\fR from the Target subsection describing --root-deps? Was it wrong? I tried to give a quick overview over how cross-compilation is handled and what behaviour to expect. The default for --root-deps is actually all deps (DEPEND, RDEPEND, and PDEPEND). For --root-deps=rdeps it's RDEPEND and PDEPEND. -- Thanks, Zac
