Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)
On Sat, Sep 01, 2012 at 05:20:02PM -0700, Brian Harring wrote This approach is fine imo, although I'd *potentially* look at adding a magic $PROC_COUNT var that is the # of cpu threads on the system; either that or defaulting jobs to it. I rather dislike requiring users to go jam a 2/4/8 in there when it's easy to compute. That said, it's minor. Either way, yes, I think EJOBS should be in EAPI5. One question about the suggested EJOBS variable; will it over-ride MAKEOPTS? Every so often on the Gentoo-user list, someone comes along with a mysterious build failure. The first suggestion is to reset MAKEOPTS to -j1. And on some occasions, that is indeed the solution to the mysterious build failure. Even the Gentoo manual agrees that the CPUs + 1 rule-of-thumb doesn't always work... http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#installing_portagesays... With MAKEOPTS you define how many parallel compilations should occur when you install a package. A good choice is the number of CPUs (or CPU cores) in your system plus one, ***BUT THIS GUIDELINE ISN'T ALWAYS PERFECT.*** (emphasis mine) I set -j1 and leave it that way. Yes, the builds take longer, but the resulting binary is just as fast. And the amount of time I save will be blown away the first time I end up screwing around a couple of hours trying to fix a mysterious build failure. That's why I want the user to have the option of over-riding EJOBS, should it ever be implemented. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
Hello, As Sid Hayn raised today on #gentoo-portage, it would be useful to finally have portage able to fetch updates from VCS-es independently of src_unpack(). This could be used, for example, on machines temporarily connected to the network -- one would then fetch files while connected to the network, and perform the updates later. There are a few ways how we could handle that but the cleanest and most universal one seems to be defining a src_fetch() phase function in a future EAPI. In the EAPIs supporting src_fetch(), that phase function would be used by PM when requesting the files to be fetched. A default_src_fetch() will be declared as well, providing implementation-defined code fetching files like they are fetched now. Older EAPIs will simply always use that default. The phase function would be disjoint from the normal merge process, much like pkg_pretend(). In portage, it will be called as 'portage' user if FEATURES=userfetch is enabled. VCS eclasses supporting separated fetching would define two phase functions: - src_fetch() which would be responsible for fetching updates, - src_unpack() which would be responsible for checking out the source to work directory. The remaining issue is handling dependencies on the tools necessary to do fetching. For default_src_fetch(), we can assume that the package manager provides the necessary tools. For custom src_fetch(), we would need either to: 1) require satisfying whole DEPEND when fetching -- probably pointless, as it will make --fetchonly almost impossible when doing initial installs; 2) introduce a new dependency type (please do not get into details how we do it -- we will discuss that another time, at the moment please just keep it as 'new dependency type') -- and we probably end up having a switch for --fetchonly without installing deps (thus omitting packages where they are not satisfied), and with deps; 3) [ugly!] assume that src_fetch() should check for its deps and fail if they are not satisfied. If that's mostly for live ebuilds, it may be acceptable. Then the package manager will just have one 'fetch failed' on --fetchonly (or early pre-fetch), and it will have to invoke src_fetch() after satisfying the deps, before src_unpack(). What do you think? What are your ideas, suggestions? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/04/2012 12:43 PM, Michał Górny wrote: Hello, As Sid Hayn raised today on #gentoo-portage, it would be useful to If you insist on using real names mine is Rick ;-) finally have portage able to fetch updates from VCS-es independently of src_unpack(). This could be used, for example, on machines temporarily connected to the network -- one would then fetch files while connected to the network, and perform the updates later. There are a few ways how we could handle that but the cleanest and most universal one seems to be defining a src_fetch() phase function in a future EAPI. In the EAPIs supporting src_fetch(), that phase function would be used by PM when requesting the files to be fetched. A default_src_fetch() will be declared as well, providing implementation-defined code fetching files like they are fetched now. Older EAPIs will simply always use that default. The phase function would be disjoint from the normal merge process, much like pkg_pretend(). In portage, it will be called as 'portage' user if FEATURES=userfetch is enabled. VCS eclasses supporting separated fetching would define two phase functions: - src_fetch() which would be responsible for fetching updates, - src_unpack() which would be responsible for checking out the source to work directory. The remaining issue is handling dependencies on the tools necessary to do fetching. For default_src_fetch(), we can assume that the package manager provides the necessary tools. For custom src_fetch(), we would need either to: 1) require satisfying whole DEPEND when fetching -- probably pointless, as it will make --fetchonly almost impossible when doing initial installs; 2) introduce a new dependency type (please do not get into details how we do it -- we will discuss that another time, at the moment please just keep it as 'new dependency type') -- and we probably end up having a switch for --fetchonly without installing deps (thus omitting packages where they are not satisfied), and with deps; 3) [ugly!] assume that src_fetch() should check for its deps and fail if they are not satisfied. If that's mostly for live ebuilds, it may be acceptable. Then the package manager will just have one 'fetch failed' on --fetchonly (or early pre-fetch), and it will have to invoke src_fetch() after satisfying the deps, before src_unpack(). What do you think? What are your ideas, suggestions? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQRjQeAAoJEKXdFCfdEflKdDAP/jyV8+NwEBX+etKq7e+qzbVg oIgjqOLfqYEmbEkO9WMsUltsf8YATy9zGB1itRiLUb5v+eptjEDvp2dx/AA4YVio RLYwtMBJsESXd6d+3PbCTeoZHTZwb7ue6yY+qC0auyC4mD6nrkDY8swungcDwFHN GZ99gAtRnQ5h8+phrKHyWzePTkBN5+32GCIn2XfRwMo+T0tGyTeMGqYfPJPlEu0y LNJmdBU0TfzE7N8QA4sp/IDQQvBmZNpH6aQM+zkJWpvBUXBATdIPZZHBAy55TWaJ t9KxiHD6XF/h0ShlTIpsbfSj31FTil2l/LfhAQdXSrB4GPxLaoovOJb2vl9L+ZyP QJclNeL1kNaOO1MIm20tGJOV6Wh0iHsn/fJlbh4YYn4PaNF+F+UXyp69uGcniuCe PxFC/aosq39LoFRrZdyRfx3DWPXnhYfcFWRwEDosa/Qb/Mbljs+BZRRPIB2Y8ItV 9j5WokM6BkNPNeoNnaS1JvCaac7xiurizs7IaXxfYC5q8aZja1OdDrV9Jh7KxIUe q8rsKMk6y9KqGvSBfW3Y9JDgIdUUG8x0bVM/j9+gqOtPH5uFgPRnZxX/Hfb0+1J5 iLjFXgwLl2AtEuflY07KfKB9xyEV58x8gkCo/BUX8Y8E6re5/4o+kNiArQL2Z+YS SOD2BmvyVHOlurug9Lq4 =FOao -END PGP SIGNATURE-
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny mgo...@gentoo.org wrote: Hello, As Sid Hayn raised today on #gentoo-portage, it would be useful to finally have portage able to fetch updates from VCS-es independently of src_unpack(). This could be used, for example, on machines temporarily connected to the network -- one would then fetch files while connected to the network, and perform the updates later. There are a few ways how we could handle that but the cleanest and most universal one seems to be defining a src_fetch() phase function in a future EAPI. In the EAPIs supporting src_fetch(), that phase function would be used by PM when requesting the files to be fetched. A default_src_fetch() will be declared as well, providing implementation-defined code fetching files like they are fetched now. Older EAPIs will simply always use that default. The phase function would be disjoint from the normal merge process, much like pkg_pretend(). In portage, it will be called as 'portage' user if FEATURES=userfetch is enabled. VCS eclasses supporting separated fetching would define two phase functions: - src_fetch() which would be responsible for fetching updates, - src_unpack() which would be responsible for checking out the source to work directory. The 'checking out' language for src_unpack() sounds like it assumes a DVCS such as mercurial or git. What about cvs or svn, where fetching is also checking out? (This is probably a trivial thing to clear up, though.) Also, where would the local copy go? distfiles? It's common for distfiles to be stored on, e.g. an NFS mount, so you may need to be careful not to place repositories there which have filesystem semantics that are disagreeable to NFS. (The only example I know of off the top of my head is svn, where the documentation warns against using the dbd backend on top of NFS.) Other common remote mounts (such as cifs) may have restrictions that could force munging of filenames, too, and VCS infrastructures (or even unpacked checkouts with strange filenames) placed on those filesystems may have unanticipated results. It may be helpful to have some kind of adapter mount in place, or even generate a tarball of the local copy and store that instead. (That'd be problematic if multiple boxes were modifying the local copy on the same share, but that's obviously problematic anyway.) -- :wq
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/04/2012 12:43 PM, Michał Górny wrote: Hello, As Sid Hayn raised today on #gentoo-portage, it would be useful to finally have portage able to fetch updates from VCS-es independently of src_unpack(). This could be used, for example, on machines temporarily connected to the network -- one would then fetch files while connected to the network, and perform the updates later. There are a few ways how we could handle that but the cleanest and most universal one seems to be defining a src_fetch() phase function in a future EAPI. In the EAPIs supporting src_fetch(), that phase function would be used by PM when requesting the files to be fetched. A default_src_fetch() will be declared as well, providing implementation-defined code fetching files like they are fetched now. Older EAPIs will simply always use that default. The phase function would be disjoint from the normal merge process, much like pkg_pretend(). In portage, it will be called as 'portage' user if FEATURES=userfetch is enabled. VCS eclasses supporting separated fetching would define two phase functions: - src_fetch() which would be responsible for fetching updates, - src_unpack() which would be responsible for checking out the source to work directory. The remaining issue is handling dependencies on the tools necessary to do fetching. For default_src_fetch(), we can assume that the package manager provides the necessary tools. For custom src_fetch(), we would need either to: 1) require satisfying whole DEPEND when fetching -- probably pointless, as it will make --fetchonly almost impossible when doing initial installs; 2) introduce a new dependency type (please do not get into details how we do it -- we will discuss that another time, at the moment please just keep it as 'new dependency type') -- and we probably end up having a switch for --fetchonly without installing deps (thus omitting packages where they are not satisfied), and with deps; 3) [ugly!] assume that src_fetch() should check for its deps and fail if they are not satisfied. If that's mostly for live ebuilds, it may be acceptable. Then the package manager will just have one 'fetch failed' on --fetchonly (or early pre-fetch), and it will have to invoke src_fetch() after satisfying the deps, before src_unpack(). I believe the easiest (and honestly most sane) method is to simply have src_fetch in the live classes check for needed deps and die (with a please emerge blah) if deps are not found. Adding something like FDEPEND just seems to be getting way too crazy on the dependency tree AND would require things to build during fetch-only which doesn't make sense. Thanks, Zero What do you think? What are your ideas, suggestions? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQRjTjAAoJEKXdFCfdEflKGPoP+wYhzeFNcXO9Lv4qm5/oPXuC RIrCs2q6erWxowFbiTO//XILVbiH1nHBWx/uJV9S0hTM+dBRIh/zZaCXy5PYnLrK dTKiHgmpNPgTQ41QGI7BZl4lQFGLgGfdJnCncSTLmLZQtMGwXD4jZ8SQ/QE1wbwK rpHtYQ/Z5kUKFJG25MRFtFZ2ifZQVpVIPmmrFfyDh+1l9Oh8AtF6XKZTriwX1ppG osPz8jo2XtoYejqvD0kFEZwc5C7FKmULYyrB+tcl5dmOgf60LvcDTBkUGi7U2ewk DWhVoLX0zXWMZfoEi3c6GRsJgZ81yXIMfPC+SUYipdfBvdH6iWYuxfgJpSioUtbV s4xC4IyOGQehnt8OAe5PpHHJcqxlDVXidmVz0sKkmJB3dM6rIsamiNZajmKVrnyh 1zle8g4XBP8AFg/fB+OiOSuYNoI5GnC2D/rp7zAtajl+0GtVWvApPUFEa0DP8LlR bYXMIGpx+LAi9rYlEdNs3tW1C4OVjZpCKYU7cjNO15f2ZOVX4WNmAWtRmpoG6O5l zL1Mv6DRgdtoITfYfogupZBgjynHsCzKL1Mb2skqtmJ853ZjV4HGgXqxcica12O7 EoJ65EU5rrzCGSUz5rqunNwK9A11VBjxXWJ/e29NKt2vACxRuiwMXkl7EK2a/oCA pTBk5q6CvQFJCyzw2bee =ueCf -END PGP SIGNATURE-
Re: [gentoo-dev] EJOBS variable for EAPI 5?
On 09/04/2012 04:00 AM, Walter Dnes wrote: On Sat, Sep 01, 2012 at 05:20:02PM -0700, Brian Harring wrote This approach is fine imo, although I'd *potentially* look at adding a magic $PROC_COUNT var that is the # of cpu threads on the system; either that or defaulting jobs to it. I rather dislike requiring users to go jam a 2/4/8 in there when it's easy to compute. That said, it's minor. Either way, yes, I think EJOBS should be in EAPI5. One question about the suggested EJOBS variable; will it over-ride MAKEOPTS? Every so often on the Gentoo-user list, someone comes along with a mysterious build failure. The first suggestion is to reset MAKEOPTS to -j1. And on some occasions, that is indeed the solution to the mysterious build failure. That would be due to a missing dependency in the Makefiles, and using -j1 is just a workaround. The ebuild can be hardcoded to use emake -j1 until the Makefile gets fixed. I set -j1 and leave it that way. Yes, the builds take longer, but the resulting binary is just as fast. And the amount of time I save will be blown away the first time I end up screwing around a couple of hours trying to fix a mysterious build failure. That's why I want the user to have the option of over-riding EJOBS, should it ever be implemented. You could use EXTRA_EMAKE for that. You can do per-package settings via /etc/portage/package.env. -- Thanks, Zac
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/2012 01:02 PM, Michael Mol wrote:
On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny mgo...@gentoo.org wrote:
Hello,
As Sid Hayn raised today on #gentoo-portage, it would be useful to
finally have portage able to fetch updates from VCS-es independently
of src_unpack(). This could be used, for example, on machines
temporarily connected to the network -- one would then fetch files
while connected to the network, and perform the updates later.
There are a few ways how we could handle that but the cleanest and most
universal one seems to be defining a src_fetch() phase function
in a future EAPI.
In the EAPIs supporting src_fetch(), that phase function would be used
by PM when requesting the files to be fetched. A default_src_fetch()
will be declared as well, providing implementation-defined code
fetching files like they are fetched now. Older EAPIs will simply
always use that default.
The phase function would be disjoint from the normal merge process,
much like pkg_pretend(). In portage, it will be called as 'portage'
user if FEATURES=userfetch is enabled.
VCS eclasses supporting separated fetching would define two phase
functions:
- src_fetch() which would be responsible for fetching updates,
- src_unpack() which would be responsible for checking out the source
to work directory.
The 'checking out' language for src_unpack() sounds like it assumes a
DVCS such as mercurial or git. What about cvs or svn, where fetching
is also checking out? (This is probably a trivial thing to clear up,
though.)
Also, where would the local copy go? distfiles? It's common for
distfiles to be stored on, e.g. an NFS mount, so you may need to be
careful not to place repositories there which have filesystem
semantics that are disagreeable to NFS. (The only example I know of
off the top of my head is svn, where the documentation warns against
using the dbd backend on top of NFS.)
Other common remote mounts (such as cifs) may have restrictions that
could force munging of filenames, too, and VCS infrastructures (or
even unpacked checkouts with strange filenames) placed on those
filesystems may have unanticipated results.
It may be helpful to have some kind of adapter mount in place, or even
generate a tarball of the local copy and store that instead. (That'd
be problematic if multiple boxes were modifying the local copy on the
same share, but that's obviously problematic anyway.)
All the live eclasses already drop a checkout (or whatever term you
like) of the repo in /usr/portage/distfiles. What we are talking about
here is separating the download/checkout into /usr/portage/distfiles
from the copy from /usr/portage/distfiles to ${S}. Making this two
separate phases would allow a reasonably sane emerge -f blah support
to fetch the live sources before build.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQRjk9AAoJEKXdFCfdEflKeocQAJgSMaycMkvmdalYWUBU4lRJ
eNilSxWoMAuln+1FMRv9HxavQCMzkw/h9o3Lwy75Kv2+Z/MZy60caG7yplexSKEf
Z3apTwU1Cbj7WasDNkNRXgoHHsn55Fnr28lueFmcAlvMWDnBV0TmXCYFiRh961hN
7Co3wbHT4ahk1TTTURFDoWbE2R24e1UJFzrWRRO4oyoIDqPqOIOqhR+4Nnl5vsXa
/UQmvIqgzxlWgdjeaWceQxgexPt0g+ZwFUFIF6FhL3xqoF6kokBj64VxPRAgK05X
x78LSsul+A0H6sAU4S9e5CmZekxFyNanF3PJ5aZaAfp8dPTWaUFIhJHh3jDFktdT
zaO1LVpEOVnUenuV6XgpETN8XxThZHzXFRokuyR3Aza41/p3eg/jo07DGmUBLRP2
fu9h/ZVwrcPixgpTNd2+8YhxIxuoka7CmJiVb4ncAJ/Yp95G64dM57DXf46rKPTC
6LX/5jQgXcR+WbQswLumZJ+EJ7aIzGhJRFGXZmbNvWVrzFxfB7vtgUl6NUsKmzTo
gffrxrZexzlnvkCThrdM1C89BdAdkWATICiAAEkf2P9gzEdtB+p65VBqYcNzFc+Q
X9kw+X6lnAn6D/KqJdSAG9plhjRuZ9JTGnZ/ZlucyP7uVnmHV5+NOVn5MYvZ/Sso
z2F4QPIJi3C9LQkOSyKF
=vy05
-END PGP SIGNATURE-
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
On Tue, 4 Sep 2012 13:02:36 -0400 Michael Mol mike...@gmail.com wrote: On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny mgo...@gentoo.org wrote: Hello, As Sid Hayn raised today on #gentoo-portage, it would be useful to finally have portage able to fetch updates from VCS-es independently of src_unpack(). This could be used, for example, on machines temporarily connected to the network -- one would then fetch files while connected to the network, and perform the updates later. There are a few ways how we could handle that but the cleanest and most universal one seems to be defining a src_fetch() phase function in a future EAPI. In the EAPIs supporting src_fetch(), that phase function would be used by PM when requesting the files to be fetched. A default_src_fetch() will be declared as well, providing implementation-defined code fetching files like they are fetched now. Older EAPIs will simply always use that default. The phase function would be disjoint from the normal merge process, much like pkg_pretend(). In portage, it will be called as 'portage' user if FEATURES=userfetch is enabled. VCS eclasses supporting separated fetching would define two phase functions: - src_fetch() which would be responsible for fetching updates, - src_unpack() which would be responsible for checking out the source to work directory. The 'checking out' language for src_unpack() sounds like it assumes a DVCS such as mercurial or git. What about cvs or svn, where fetching is also checking out? (This is probably a trivial thing to clear up, though.) They either stay with src_unpack() or do 'cvs up' in src_fetch() and just copy files over in src_unpack(). Anyway, that's what they do now -- update the copy in distfiles/cvs-src and then copy it. Also, where would the local copy go? distfiles? It's common for distfiles to be stored on, e.g. an NFS mount, so you may need to be careful not to place repositories there which have filesystem semantics that are disagreeable to NFS. (The only example I know of off the top of my head is svn, where the documentation warns against using the dbd backend on top of NFS.) The actual code will be eclass-dependent, so it will go whatever it goes now. No magic, no exherbo. Just plain phase function. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote: I believe the easiest (and honestly most sane) method is to simply have src_fetch in the live classes check for needed deps and die (with a please emerge blah) if deps are not found. Adding something like FDEPEND just seems to be getting way too crazy on the dependency tree AND would require things to build during fetch-only which doesn't make sense. I think it's nicer to have FDEPEND because it makes the deps more complete, so the package manager can bail out when necessary, without even executing src_fetch. In the case of --fetchonly the package manager could simply bail out if the deps are not installed (like how it bails out for --buildpkgonly when the deps aren't installed). -- Thanks, Zac
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/09/12 01:32 PM, Zac Medico wrote: On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote: I believe the easiest (and honestly most sane) method is to simply have src_fetch in the live classes check for needed deps and die (with a please emerge blah) if deps are not found. Adding something like FDEPEND just seems to be getting way too crazy on the dependency tree AND would require things to build during fetch-only which doesn't make sense. I think it's nicer to have FDEPEND because it makes the deps more complete, so the package manager can bail out when necessary, without even executing src_fetch. In the case of --fetchonly the package manager could simply bail out if the deps are not installed (like how it bails out for --buildpkgonly when the deps aren't installed). Just looking into the future here; would things like archivers or other helpers used by src_unpack move to FDEPEND as well? or would this be limited solely to tools that data transfer? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBGXQYACgkQ2ugaI38ACPDKGwEAlvqkQHBv2vDtGfYNYrIIMIV9 1le8HgtXRhIu9FOhw1EA/3m1xc4zNcWMslK6RiV5sn4mBVXUQt6Ry2m/Nar+ccFq =DqcL -END PGP SIGNATURE-
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/04/2012 03:56 PM, Ian Stakenvicius wrote: On 04/09/12 01:32 PM, Zac Medico wrote: On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote: I believe the easiest (and honestly most sane) method is to simply have src_fetch in the live classes check for needed deps and die (with a please emerge blah) if deps are not found. Adding something like FDEPEND just seems to be getting way too crazy on the dependency tree AND would require things to build during fetch-only which doesn't make sense. I think it's nicer to have FDEPEND because it makes the deps more complete, so the package manager can bail out when necessary, without even executing src_fetch. In the case of --fetchonly the package manager could simply bail out if the deps are not installed (like how it bails out for --buildpkgonly when the deps aren't installed). Just looking into the future here; would things like archivers or other helpers used by src_unpack move to FDEPEND as well? or would this be limited solely to tools that data transfer? We are talking about things required for src_fetch (the download) so no, things required for src_unpack have no real place in this as far as I am concerned. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQRl8nAAoJEKXdFCfdEflKoA0P/152JYx2/62tou9kcUCEILkz DXGfO5bY+A1DYrCsVAR9H7C4dzmrULU0JNjUl3nMpGFKXMAvWQbai2uDICMECZVg QCwHVzxyHD9TzdVAyp928dtn/FtnPvaUV8WHIugFuaZZM/mmACsyEYxFqusMXu51 KkMzs1F9TatL3uoAMuvT0KLiMWHmxw6OrmMrqRX1T7gP4AIy7cD5h8v7DOzWORLQ x12/HGAA2HLDgfhwrNymRs+OIqSLXE54DmAfvOglB6Jfw/I/N6HoY1PQ1vZaW7jU P+t2l7VbRsINmHUk+tbl+7A5F2XBE5GphSh8oIN7yuToSwtbstlGFmTGhb/V0gpM HUpI5v/6B40fc+DgEuAMAZjhUBT+1YIbIO9WVUaXN/I9JBA22FBZSm4qu59qWg/U DX+Jhul9M+A5QPdNBios0K5BYxFXamx/i52w/361NdLV2Onn1zHQT95oC7RKOGJG fZu6PhtkW7Z/CaYSja7TKa8H5pl/+Bj5Mgz7cGlwz41AP4Q6+omfnxlLf+iJME07 rBfKe4RuhZuUXamu+SfW7OdNY8Zqm9skSGw1HbHFVHDQIXKtt8Pv9tr1m364h+W9 r6SUE1xdJaCbtzh2/ajpu9EIVLoVuW/NEFvQIMd7wn3R2PTKgNHOnkLB6c8j/qaa nWe+jCpIt2uSd2Syceqh =4kd2 -END PGP SIGNATURE-
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
On Tue, 04 Sep 2012 15:56:54 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/09/12 01:32 PM, Zac Medico wrote: On 09/04/2012 10:05 AM, Rick Zero_Chaos Farina wrote: I believe the easiest (and honestly most sane) method is to simply have src_fetch in the live classes check for needed deps and die (with a please emerge blah) if deps are not found. Adding something like FDEPEND just seems to be getting way too crazy on the dependency tree AND would require things to build during fetch-only which doesn't make sense. I think it's nicer to have FDEPEND because it makes the deps more complete, so the package manager can bail out when necessary, without even executing src_fetch. In the case of --fetchonly the package manager could simply bail out if the deps are not installed (like how it bails out for --buildpkgonly when the deps aren't installed). Just looking into the future here; would things like archivers or other helpers used by src_unpack move to FDEPEND as well? or would this be limited solely to tools that data transfer? src_fetch() only. Archivers belong to src_unpack(), which belongs to the main phase function cycle - DEPEND. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
Just looking into the future here; would things like archivers or other helpers used by src_unpack move to FDEPEND as well? or would this be limited solely to tools that data transfer? We should keep the data transfer and the unpack phase clearly separated. So, this would best really be for data transfer only. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Now with a handy function for cmake autotools! And a more complete
description.
---
gx86/eclass/boost-utils.eclass | 99 ++
1 file changed, 99 insertions(+)
create mode 100644 gx86/eclass/boost-utils.eclass
diff --git a/gx86/eclass/boost-utils.eclass b/gx86/eclass/boost-utils.eclass
new file mode 100644
index 000..c720fe7
--- /dev/null
+++ b/gx86/eclass/boost-utils.eclass
@@ -0,0 +1,99 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+if [[ ! ${_BOOST_ECLASS} ]]; then
+
+# @ECLASS: boost-utils.eclass
+# @MAINTAINER:
+# Michał Górny mgo...@gentoo.org
+# Tiziano Müller dev-z...@gentoo.org
+# Sebastian Luther sebastianlut...@gmx.de
+# Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com
+# @BLURB: helper functions for packages using Boost C++ library
+# @DESCRIPTION:
+# Helper functions to be used when building packages using the Boost C++
+# library collection.
+#
+# For cmake autotools it is usually necessary to set BOOST_ROOT using
+# boost-utils_export_root. However, other build system may require more
+# hackery or even appending -I$(boost-utils_get_includedir) to CFLAGS
+# and -L$(boost-utils_get_libdir) to LDFLAGS.
+#
+# If the package supports the newest version of boost, it should depend
+# on =dev-libs/boost-x.y.z (min version) or just dev-libs/boost. If it
+# doesn't, you should set BOOST_MAX_VERSION (or just pass the correct
+# slot to the used function) and depend on dev-libs/boost:x.y.
+
+case ${EAPI:-0} in
+ 0|1|2|3|4) ;;
+ *) die ${ECLASS}.eclass API in EAPI ${EAPI} not yet established.
+esac
+
+inherit multilib versionator
+
+# @ECLASS-VARIABLE: BOOST_MAX_VERSION
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The maximal (newest) boost version supported by the package. If unset,
+# the newest installed version will be used.
+#
+# Please note that if BOOST_MAX_VERSION is set, the package should
+# depend on boost packages with *exactly* that slot (i.e. boost:1.47);
+# otherwise, the package should depend on boost without a slot
+# specified (i.e. =boost-1.45).
+
+# @FUNCTION: boost-utils_get_best_slot
+# @DESCRIPTION:
+# Get newest installed slot of Boost.
+boost-utils_get_best_slot() {
+ local pkg=dev-libs/boost
+ local atom=$(best_version ${pkg})
+ get_version_component_range 1-2 ${atom#${pkg}}
+}
+
+# @FUNCTION: boost-utils_get_includedir
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Get the includedir for the given Boost slot. If no slot is given,
+# defaults to ${BOOST_MAX_VERSION}. If that variable is unset,
+# the newest installed slot will be used.
+#
+# Outputs the sole path (without -I).
+boost-utils_get_includedir() {
+ local slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}
+ has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
+
+ echo -n ${EPREFIX}/usr/include/boost-${slot/./_}
+}
+
+# @FUNCTION: boost-utils_get_libdir
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Get the libdir for the given Boost slot. If no slot is given, defaults
+# to ${BOOST_MAX_VERSION}. If that variable is unset, the newest
+# installed slot will be used.
+#
+# Outputs the sole path (without -L).
+boost-utils_get_libdir() {
+ local slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}
+ has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
+
+ echo -n ${EPREFIX}/usr/$(get_libdir)/boost-${slot/./_}
+}
+
+# @FUNCTION: boost-utils_export_root
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Set the BOOST_ROOT variable to includedir for the given Boost slot.
+# If no slot is given, defaults to ${BOOST_MAX_VERSION}. If that
+# variable is unset, the newest installed slot will be used.
+#
+# This variable satisfies both cmake and sys-devel/boost-m4 autoconf
+# macros.
+boost-utils_export_root() {
+ export BOOST_ROOT=$(boost-utils_get_includedir ${@})
+}
+
+_BOOST_ECLASS=1
+fi # _BOOST_ECLASS
--
1.7.12
Re: [gentoo-dev] EAPI usage
On Sun, Sep 02, 2012 at 10:36:13AM -0400, Michael Orlitzky wrote: On 09/02/2012 09:46 AM, Rich Freeman wrote: On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: What I dont actually understand at all is why bumping the EAPI should be so complicated or involved that it even deserves so much resistance... rantOk, it REALLY annoys me when people pull out this kind of a line in an argument... If it isn't all that complicated or involved and it just makes so much sense, then why do we bother to waste time asking for it to be made policy, since obviously everybody will just do it anyway... Believe it or not, people who take up an opposing side in a debate don't ALWAYS do it because they're simply dumber than you. That is, unless they're arguing with me... :) /rant I think everyone would be happier if all ebuilds in the tree were EAPI4. On the other hand, Rich is right that making this a policy will have the opposite of the intended effect: developers just won't fix bugs in EAPI4 ebuilds when they don't have time to do the EAPI bump (one could easily spend a few hours on this). As a compromise, it could be made policy that bump to EAPI=foo bugs are valid. If someone would benefit from such a bump, he can file a bug and know that it won't be closed WONTFIX. On the other hand, the dev is under no more pressure than usual to do the bump. If you attach a patch and have done the legwork, sure. If you're just opening bugs w/ bump to EAPI=monkeys, bluntly, it's noise and it's annoying. EAPI bump requests for pkgs that need to move forward so an eclass can be cleaned up/moved forward, sure, but arbitrary please go bump xyz without a specific reason (and/or legwork done if not) isn't helpful. Kind of equivalent to zero-day bump requests in my view in terms of usefulness. ~harring
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31-08-2012 20:46, Ciaran McCreesh wrote: snip Also, we're getting rather a lot of *DEPEND variables here... If we're making people make major changes to their deps, which for HDEPEND we definitely would be, then the it's expensive since people would have to redo their deps argument against a combined DEPENDENCIES variable goes out of the window, so we should rethink that too. I have to agree with Ciaran, instead of multiplying DEPEND variables, it's probably time we move to a single DEPENDENCIES variable. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQRpeVAAoJEC8ZTXQF1qEP/UgQALd+7oqAODQA5bXdyqV+Qix+ mDN66c/6UO4VS2dyhfCEyA3osJzFS4u6mIuR7uFpXoKXGGs+MYdl7EG9C0k48zUu YLCDD56oyk6wACxBk7EHWVql1rvFoFemMUw5YUVq71w3FU9hrpBi/DXKsoAlCRyw 4B2p6t8p6efll3vzbcz7M0LZseiox4GBTFCrtxR5zwgvx3b0gKvgU1Pv+AT3SBQK J3IOxb09GSLCJKo56+iDHGuS5RwBBmdWP9l3+AdbjR2LoQ05f8o8a7/geg1Qqg/Z gVVSo4WDN2kIDJOvCBuXuo95a0KKFt/zUgfwjsqe02fRu2mDiWAju4L6vk2WE316 4yfMULI6HrVUk3ra+O4ZW7eoOuRvPVDpr4vyCVetFe4bx+zmlo/CmzOg/2teMyoc rlMvOigR/4D+wxX7mbw/0fwZ5tVUbZ2pkdEhKetlpDe+xbWY0LhaczKdizwF7BrT d+BeazPGWBP/muY0s3VDu3KV/3TRS0tME8GRsDevA9nCfA2plU0ZmmZnTB69tLc+ /dgdexHhc3IuA5eMObwOfSK6r9Jozlrv09TDvb6kHXm+0kqhV/W/aaS1qT4Bjlxd psMjf9lSJHLcXuhtOz9OW4qmhp4BGCA8Rgeoq25Yw8E2eH0abvDbHR5U7u1hEpnQ j6rJ0fZ27tfbMecd5i8b =Zv/I -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI usage
On 09/04/2012 05:06 PM, Brian Harring wrote: As a compromise, it could be made policy that bump to EAPI=foo bugs are valid. If someone would benefit from such a bump, he can file a bug and know that it won't be closed WONTFIX. On the other hand, the dev is under no more pressure than usual to do the bump. If you attach a patch and have done the legwork, sure. If you're just opening bugs w/ bump to EAPI=monkeys, bluntly, it's noise and it's annoying. EAPI bump requests for pkgs that need to move forward so an eclass can be cleaned up/moved forward, sure, but arbitrary please go bump xyz without a specific reason (and/or legwork done if not) isn't helpful. Kind of equivalent to zero-day bump requests in my view in terms of usefulness. Except this is what we have now, and isn't a compromise at all.
