Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 00:12:53 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Mike Frysinger posted on Thu, 30 Aug 2012 19:46:21 -0400 as excerpted: On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote: On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote: On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote: On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote: keeping things in @system doesn't make much sense: - there's a penalty (as noted in old threads) - it isn't actually required at runtime, so it's bloat on reduced systems I think it's practically the same as compiler. that isn't a bad view point, but for the purposes of this discussion, i don't think it's relevant :) Will it be a better view point if I opened a separate discussion about putting pkg-config in @system? It could get more attention probably. my answer would still be a very strong no Agreed. Various people have in fact expressed a desire to REDUCE the number of packages in @system, for various reasons including both the parallel merge penalty and the bloat on reduced systems. In practice, there's not a lot of positive movement on actually reducing @system, but at minimum, unless there's *NO* other choice and in this case there clearly is, we shouldn't be ADDING packages to @system. For that reason, while I do see the reason why some would like pkg-config added to @system, the whole idea's pretty much a non-starter, as it WILL get a lot of push-back. In theory it /might/ be forceable, but I just don't see how the cost, political, in time to push thru, and technical (given the technical reasons listed above), makes it worth pursuing in the slightest. It's just not worth going there. But you're aware that cost of pkgconf is very little? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] doheader function for EAPI 5?
Hi all, A new doheader (and newheader) helper function is on our list of possible EAPI 5 features. It would be very easy to implement, just copy the code from doconfd or doenvd. However, this function was suggested in Bug 21310 [1] which was filed in 2003. The absence of any activity there makes me wonder if anybody cares about the feature? Ulrich [1] https://bugs.gentoo.org/show_bug.cgi?id=21310
[gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)
On Thu, 4 Dec 2008, Diego 'Flameeyes' Pettenò wrote:
Since not all the buildsystem we support use make for the actual
build, and they don't necessarily support make-like options (-jX -s
and so on), it would be nice to be able to express a JOBS variable
that could be used for parallel build with any build systems.
Right now there are ebuilds like openoffice or some scons-based
ebuilds that parse MAKEOPTS and get out of that the number of jobs
from the -j option, but this is a) suboptimal b) error-prone.
One has to consider people might be using -l for parallel building
too, for which reasons I'd be suggesting doing something like this to
make the change transparent:
- ebuilds using non-make build systems would use JOBS;
- ebuilds using make builds systems would just use emake as usual;
- Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS;
- if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS};
- if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l).
The result is that you can finally combine -l with parallel build on
OpenOffice and other packages, with a fallback number of maximum jobs
instead of using load-based decisions.
Coming back to this old topic [1]. Is there still consensus that we
should have such an EJOBS variable? (It shouldn't be called JOBS because
this name is too generic, see the old discussion.) Then we could add it
to EAPI 5.
Ulrich
[1]
http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml
Re: [gentoo-dev] doheader function for EAPI 5?
On 8/31/12 10:20 AM, Ulrich Mueller wrote: A new doheader (and newheader) helper function is on our list of possible EAPI 5 features. It would be very easy to implement, just copy the code from doconfd or doenvd. I'm somewhat interested. Here's the current code dev-lang/v8 uses to install headers: insinto /usr doins -r include || die Using e.g. doheader include/* is slightly prettier IMHO, but it's not a big deal. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI usage
Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman: On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber j...@gentoo.org wrote: scarabeus suggested the change dev should use latest eapi when bumping to dev must use latest eapi when bumping if not forbidden by eclasses. He was asked to bring it up on the mailing lists, to get a better definition of when what EAPI should be used. I raised the issue through scarabeus, as in my opinion there is no reason to not use latest EAPI. So please discuss. I can't say I'm a big fan of this. This requires forcing changes to ebuilds that offer no actual benefit to either the maintainer or the end-users (changes that actually have some benefit to either are likely to be made anyway). The PM maintainers have chimed in that there is no benefit to PM maintenance from this change. So, I can't really see what the upside of such a policy is. rant Let's say, we as in Gentoo decide that we're completely sick of keeping all that old code out there adjusted to newer and newer gcc versions that are more and more critical towards minor details of the c++ standards. So, we declare that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever and dont bother anymore with all these superfluous does not build with gcc-4.7 bugs. Well, newer gcc versions might have some very minor marginal advantages, but they require that we mess with code that has worked for ages. They require that we actually give some thought on the evolution of the language semantics or nag upstream, but we can't really be bothered with that because of limited time. Also, keeping gcc-4.5 will always (trivially) keep us backward compatibility... much more important than forward compatibility, should porting to a much never future version ever become necessary. For a real world analogy, serious quakes happen only once a century... why should we even bother with improving building codes? I mean, at some point in the future things will fall apart anyway. Better dont shake anything in between. /rant Sorry but I could not really resist... please take it with a grain of salt. However, seriously, ... Give me one non-trivial ebuild where you can absolutely guarantee that a bump from EAPI=0 to EAPI=4 will not enable any improvements (in readability, failsafe behaviour and code size for example). Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, we'll have succeeded in generating an unmaintainable mess (tm). It will not be any fun to look up things in PMS anew everytime you edit something. (Was the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in pkg_preinst?) This problem could however also be solved by selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap). Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote: any fun to look up things in PMS anew everytime you edit something. (Was the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in pkg_preinst?) This problem could however also be solved by selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap). I guess you meant 1 and 2. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] EAPI usage
Am Freitag, 31. August 2012, 11:11:37 schrieb Fabian Groffen: On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote: any fun to look up things in PMS anew everytime you edit something. (Was the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in pkg_preinst?) This problem could however also be solved by selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap). I guess you meant 1 and 2. Actually I dont care... but 2 could certainly go faster than 3, true. :) -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Right now, it just contains the function Tiziano listed in his post[1].
I'd appreciate further ideas, feedback, and possibly an example from
someone who will actually need it.
---
gx86/eclass/boost-utils.eclass | 47 ++
1 file changed, 47 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..b57a400
--- /dev/null
+++ b/gx86/eclass/boost-utils.eclass
@@ -0,0 +1,47 @@
+# 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.
+
+case ${EAPI:-0} in
+ 0|1|2|3|4) ;;
+ *) die ${ECLASS}.eclass API in EAPI ${EAPI} not yet established.
+esac
+
+inherit versionator
+
+# @FUNCTION: boost-utils_get_best_slot
+# @DESCRIPTION:
+# Get newest SLOT (major version) 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 given Boost slot, or the best slot installed
+# (if no slot given). Outputs the sole path (without -I).
+boost-utils_get_includedir() {
+ local slot=${1:-$(boost-utils_get_best_slot)}
+ has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
+
+ echo -n ${EPREFIX}/usr/include/boost-${slot/./_}
+}
+
+_BOOST_ECLASS=1
+fi # _BOOST_ECLASS
--
1.7.12
Re: [gentoo-dev] EAPI usage
Am Freitag, 31. August 2012, 11:03:06 schrieb Andreas K. Huettel: Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman: On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber j...@gentoo.org wrote: scarabeus suggested the change dev should use latest eapi when bumping to dev must use latest eapi when bumping if not forbidden by eclasses. He was asked to bring it up on the mailing lists, to get a better definition of when what EAPI should be used. I raised the issue through scarabeus, as in my opinion there is no reason to not use latest EAPI. So please discuss. I can't say I'm a big fan of this. This requires forcing changes to ebuilds that offer no actual benefit to either the maintainer or the end-users (changes that actually have some benefit to either are likely to be made anyway). The PM maintainers have chimed in that there is no benefit to PM maintenance from this change. So, I can't really see what the upside of such a policy is. rant Let's say, we as in Gentoo decide that we're completely sick of keeping all that old code out there adjusted to newer and newer gcc versions that are more and more critical towards minor details of the c++ standards. So, we declare that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever and dont bother anymore with all these superfluous does not build with gcc-4.7 bugs. Well, newer gcc versions might have some very minor marginal advantages, but they require that we mess with code that has worked for ages. They require that we actually give some thought on the evolution of the language semantics or nag upstream, but we can't really be bothered with that because of limited time. Also, keeping gcc-4.5 will always (trivially) keep us backward compatibility... much more important than forward compatibility, should porting to a much never future version ever become necessary. For a real world analogy, serious quakes happen only once a century... why should we even bother with improving building codes? I mean, at some point in the future things will fall apart anyway. Better dont shake anything in between. /rant Sorry but I could not really resist... please take it with a grain of salt. However, seriously, ... Give me one non-trivial ebuild where you can absolutely guarantee that a bump from EAPI=0 to EAPI=4 will not enable any improvements (in readability, failsafe behaviour and code size for example). Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, we'll have succeeded in generating an unmaintainable mess (tm). It will not be any fun to look up things in PMS anew everytime you edit something. (Was the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in pkg_preinst?) This problem could however also be solved by selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap). Words of wisdom, nothing to add. Greetings. Cheers, Andreas Cheers, -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD
[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted: On Fri, 31 Aug 2012 00:12:53 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Various people have in fact expressed a desire to REDUCE the number of packages in @system, for various reasons including both the parallel merge penalty and the bloat on reduced systems. In practice, there's not a lot of positive movement on actually reducing @system, but at minimum, unless there's *NO* other choice and in this case there clearly is, we shouldn't be ADDING packages to @system. For that reason, while I do see the reason why some would like pkg-config added to @system, the whole idea's pretty much a non-starter But you're aware that cost of pkgconf is very little? Not really, when it's a step in the opposite direction from an intended goal. The first step toward any goal is to stop going backward, and that's exactly what this would be. We need a smaller @system, not a larger one, and while the add would be easy, undoing it years later when it's yet another bit of the tangled web woven, would be *MUCH* more difficult. Just don't do it; don't go backward; don't add to the problem instead of reducing it. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 10:06:06 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted: On Fri, 31 Aug 2012 00:12:53 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Various people have in fact expressed a desire to REDUCE the number of packages in @system, for various reasons including both the parallel merge penalty and the bloat on reduced systems. In practice, there's not a lot of positive movement on actually reducing @system, but at minimum, unless there's *NO* other choice and in this case there clearly is, we shouldn't be ADDING packages to @system. For that reason, while I do see the reason why some would like pkg-config added to @system, the whole idea's pretty much a non-starter But you're aware that cost of pkgconf is very little? Not really, when it's a step in the opposite direction from an intended goal. The first step toward any goal is to stop going backward, and that's exactly what this would be. We need a smaller @system, not a larger one, and while the add would be easy, undoing it years later when it's yet another bit of the tangled web woven, would be *MUCH* more difficult. Just don't do it; don't go backward; don't add to the problem instead of reducing it. So please introduce virtual/compiler, virtual/linker, virtual/posix-system, virtual/sratatata and add them to DEPEND of every single ebuild. I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny mgo...@gentoo.org wrote: So please introduce virtual/compiler, virtual/linker, virtual/posix-system, virtual/sratatata and add them to DEPEND of every single ebuild. Every ebuild doesn't need all of those - that is the whole point. As Duncan already pointed out, reducing @system is a goal, but it doesn't mean that we need to get there overnight. However, we'll never get there if we keep going backwards. I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. This isn't needed by every single package either. I'm all for tools that help automate DEPEND population, and I'm fine with having an ebuild template that includes gotcha depends pre-populated so that devs give them consideration (and deleting lines is easier than adding them). Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. I would think that somebody running a reduced system would be likely to be installing binary packages, or use a binary package of gcc, etc. Presumably they knew what they're getting into and for whatever reason the balance was considered acceptable for them. I would think that the sorts of people who would run reduced systems would probably not be updating them frequently anyway. There are also other benefits of reduced @system besides running a reduced system. Rich
Re: [gentoo-dev] EAPI usage
On Fri, Aug 31, 2012 at 5:03 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: rant Let's say, we as in Gentoo decide that we're completely sick of keeping all that old code out there adjusted to newer and newer gcc versions that are more and more critical towards minor details of the c++ standards. So, we declare that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever and dont bother anymore with all these superfluous does not build with gcc-4.7 bugs. That is not an appropriate analogy, as I'm not suggesting that we refuse to support newer EAPIs. I'm just saying that packages shouldn't be bumped just for the sake of bumping them. Give me one non-trivial ebuild where you can absolutely guarantee that a bump from EAPI=0 to EAPI=4 will not enable any improvements (in readability, failsafe behaviour and code size for example). Suppose for the sake of argument that no such ebuild exists. I still maintain that there is little benefit from forcing an EAPI bump on new ebuilds. If I thought that bumping the EAPI would make my life as a maintainer easier I'd just do it - I wouldn't need a policy to tell me to do it. The only reason you'd need a policy is if I as a maintainer figured that bumping the EAPI was more hassle than whatever benefits I get down the road from all those improvements. If I did think that bumping the EAPI wasn't worth the hassle, and yet I was told that I'd be banned as a dev for not doing so anyway, then obviously I'm going to do the minimum necessary to comply with policy, which means changing the EAPI line of the ebuild and only changing other lines as required to get the thing to build and comply with PMS. So, while all those benefits you named are enabled few would actually be realized. Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, we'll have succeeded in generating an unmaintainable mess (tm). It will not be any fun to look up things in PMS anew everytime you edit something. I suspect that most devs just edit things that they maintain, and that means that they can control how many EAPIs are in use in those ebuilds. Again, devs already have incentive to make their own lives earlier - we don't need to turn that into policy. I might see some benefit for devs who routinely modify stuff that they don't maintain, but that should generally be kept to a minimum anyway. If unsure how how to edit any particular ebuild, just file a bug! And if the package isn't maintained, then nobody will be bumping its EAPI anyway. Rich
Re: [gentoo-dev] Re: EAPI usage
On 08/30/2012 08:33 PM, Duncan wrote: Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted: My main concern is doing bumps all the time just for their own sake. Yes. That's why I didn't tackle that side at all. But I've seen the PM's can never drop support for an EAPI once adopted thing before, and while there's quite a possibility I'm missing something as I'm no PM expert, it does seem to me that rings hollow; that an EAPI drop COULD be done, without too much disrupting either users or devs (PM or otherwise). But as the experts say otherwise, there probably /is/ something I'm missing, which is why I asked. It would be a bad idea to remove support for *uninstalling* an ebuild with a given EAPI, since any given system that the PM encounters could potentially have ebuilds with any old EAPI installed. OTOH, removing support for *installing* a given EAPI is quite feasible. In Portage, we occasionally deprecate EAPIs that only existed for the purpose of testing. Once an EAPI is deprecated, ebuilds using that EAPI can no longer be installed, but they can still be uninstalled (including execution of pkg_prerm/pkg_postrm phases). That said, deprecation of official EAPIs such as EAPI 0, 1, and 2 would not lead to much code being removed, because the later EAPIs share so much code with them. So, deprecating official EAPIs provides little or no benefit in terms of code maintenance. -- Thanks, Zac
Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)
On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Coming back to this old topic [1]. Is there still consensus that we should have such an EJOBS variable? (It shouldn't be called JOBS because this name is too generic, see the old discussion.) Then we could add it to EAPI 5. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml If we're doing this, do we tell users to stop setting MAKEOPTS for EAPIs 5 and greater? Do we change the name of MAKEOPTS for EAPIs 5 and greater instead? Do we put fancy code in the package mangler to deal with it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI usage
On Thu, 30 Aug 2012 23:58:00 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Of course an individual PM could choose to keep support for as long as they want, but unless I'm missing something, that'd let PMs drop support for old EAPIs if desired, with at least a reasonably sane upgrade path for both PM devs and users. It's irrelevant: the amount of package mangler code to be saved by removing old EAPIs is so small it's not worth discussing. Most EAPI changes so far have either been additions or very simple behaviour tweaks, not removals of annoying things. There are things we might change in future EAPIs that will in the very long term make this discussion worthwhile. If we get rid of VDB access or unconstrained env saving, *then* it might be worth having this discussion. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 12:42:10 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 31 Aug 2012 10:06:06 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted: On Fri, 31 Aug 2012 00:12:53 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Various people have in fact expressed a desire to REDUCE the number of packages in @system, for various reasons including both the parallel merge penalty and the bloat on reduced systems. In practice, there's not a lot of positive movement on actually reducing @system, but at minimum, unless there's *NO* other choice and in this case there clearly is, we shouldn't be ADDING packages to @system. For that reason, while I do see the reason why some would like pkg-config added to @system, the whole idea's pretty much a non-starter But you're aware that cost of pkgconf is very little? Not really, when it's a step in the opposite direction from an intended goal. The first step toward any goal is to stop going backward, and that's exactly what this would be. We need a smaller @system, not a larger one, and while the add would be easy, undoing it years later when it's yet another bit of the tangled web woven, would be *MUCH* more difficult. Just don't do it; don't go backward; don't add to the problem instead of reducing it. So please introduce virtual/compiler, virtual/linker, virtual/posix-system, virtual/sratatata and add them to DEPEND of every single ebuild. I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically this doesnt really compare to gcc since its a RDEPEND for everything c++ and maybe more (i didnt check when libgcc_s is linked in or not) A.
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 10:56 AM, Alexis Ballier wrote: Michał Górny mgo...@gentoo.org wrote: I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically And realistically that's where the DEPEND should be anyways, IMO -- appended by the eclass where the function is that uses it. If this means prune_libtool_files() gets separated out of eutils and put in its own eclass (so that all the eutils inheritors don't suddenly need virtual/pkgconfig unnecessarily), then so be it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI3111dXT/z+gGUM q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad =GWHe -END PGP SIGNATURE-
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On 31 August 2012 11:05, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 10:56 AM, Alexis Ballier wrote: Michał Górny mgo...@gentoo.org wrote: I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically And realistically that's where the DEPEND should be anyways, IMO -- appended by the eclass where the function is that uses it. If this means prune_libtool_files() gets separated out of eutils and put in its own eclass (so that all the eutils inheritors don't suddenly need virtual/pkgconfig unnecessarily), then so be it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI3111dXT/z+gGUM q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad =GWHe -END PGP SIGNATURE- Also, I think that before many of these large changes happen, pkgconf should become the default choice for the virtual. I'm sure embedded or server users don't need/want Glib on their systems.
Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)
On Fri, 31 Aug 2012 15:45:21 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Coming back to this old topic [1]. Is there still consensus that we should have such an EJOBS variable? (It shouldn't be called JOBS because this name is too generic, see the old discussion.) Then we could add it to EAPI 5. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml If we're doing this, do we tell users to stop setting MAKEOPTS for EAPIs 5 and greater? How can this work ? I cant think of any simple solution. Do we change the name of MAKEOPTS for EAPIs 5 and greater instead? Do we put fancy code in the package mangler to deal with it? IMHO EAPI-5 compliant PMs should do MAKEOPTS=$MAKEOPTS -j$EJOBS for every EAPI; using EJOBS from ebuilds/eclasses is allowed only in EAPI 5 and greater. This is retroactive but could be classified 'PM internals' so its fine imho. People using such a PM and not reading the news will get the old MAKEOPTS which will still work with makefile based build systems but will get serial builds for e.g. EAPI5 ebuilds + waf based build systems. Not a very big deal. A.
Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)
On Fri, 2012-08-31 at 15:45 +0100, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Coming back to this old topic [1]. Is there still consensus that we should have such an EJOBS variable? (It shouldn't be called JOBS because this name is too generic, see the old discussion.) Then we could add it to EAPI 5. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml If we're doing this, do we tell users to stop setting MAKEOPTS for EAPIs 5 and greater? Do we change the name of MAKEOPTS for EAPIs 5 and greater instead? Do we put fancy code in the package mangler to deal with it? Users typically set MAKEOPTS systemwide in /etc/make.conf. If EJOBS will have no effect for EAPI5 ebuilds, then obviously we should not be advising users to stop using MAKEOPTS until the whole tree has migrated to EAPI5. And if EJOBS will be recognized by a future version of portage for all EAPIs, then we still should allow MAKEOPTS because some users may want to use --load-average. Changing the name of MAKEOPTS in =EAPI5 makes no sense. First, because it's a standard environment variable used by gnu make. Second, because having 3 different settings for parallel building (EJOBS, MAKEOPTS, and MAKEOPTS_EAPI5) would be insane. Fancy code in the package manager would be the way to go IMHO. Ulrich's message contains a reasonable description of the algorithm. -Alexandre. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 11:05:23 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 10:56 AM, Alexis Ballier wrote: Michał Górny mgo...@gentoo.org wrote: I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically And realistically that's where the DEPEND should be anyways, IMO -- appended by the eclass where the function is that uses it. If this means prune_libtool_files() gets separated out of eutils and put in its own eclass (so that all the eutils inheritors don't suddenly need virtual/pkgconfig unnecessarily), then so be it. I wasn't referring to the function at the moment but at the overall fact that practically any C/C++ package depending on any non-standard library practically should depend on pkg-config. A library not providing pkg-config file is simply broken. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 07:48:23 -0400 Rich Freeman ri...@gentoo.org wrote: On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny mgo...@gentoo.org wrote: So please introduce virtual/compiler, virtual/linker, virtual/posix-system, virtual/sratatata and add them to DEPEND of every single ebuild. Every ebuild doesn't need all of those - that is the whole point. As Duncan already pointed out, reducing @system is a goal, but it doesn't mean that we need to get there overnight. However, we'll never get there if we keep going backwards. Reducing @system may be a goal but it should be a *reasonable* goal. Not reducing because we can reduce but because it is bloated with unneeded software. We shouldn't even try to go below POSIX system requirements; we shouldn't remove standard Linux stuff (from Linux profiles, at least) either. And I believe toolchain belongs to @system as well; or at least the C99 compiler. And for a reasonable Gentoo toolchain, pkg-config is a must-have. At least since we deprecated and are seriously fighting libtool. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] EJOBS variable for EAPI 5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 11:27 AM, Alexandre Rostovtsev wrote: On Fri, 2012-08-31 at 15:45 +0100, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Coming back to this old topic [1]. Is there still consensus that we should have such an EJOBS variable? (It shouldn't be called JOBS because this name is too generic, see the old discussion.) Then we could add it to EAPI 5. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml If we're doing this, do we tell users to stop setting MAKEOPTS for EAPIs 5 and greater? Do we change the name of MAKEOPTS for EAPIs 5 and greater instead? Do we put fancy code in the package mangler to deal with it? Users typically set MAKEOPTS systemwide in /etc/make.conf. If EJOBS will have no effect for EAPI5 ebuilds, then obviously we should not be advising users to stop using MAKEOPTS until the whole tree has migrated to EAPI5. And if EJOBS will be recognized by a future version of portage for all EAPIs, then we still should allow MAKEOPTS because some users may want to use --load-average. Changing the name of MAKEOPTS in =EAPI5 makes no sense. First, because it's a standard environment variable used by gnu make. Second, because having 3 different settings for parallel building (EJOBS, MAKEOPTS, and MAKEOPTS_EAPI5) would be insane. Fancy code in the package manager would be the way to go IMHO. Ulrich's message contains a reasonable description of the algorithm. -Alexandre. I think, if i read the previous response to this correctly, that the suggestion isn't the removal of MAKEOPTS, but simply that the '-j' specification currently set in MAKEOPTS should instead be set in EJOBS in everyone's make.conf. This would then be appended to MAKEOPTS (for all EAPI) -and- be used for non-make build systems (for EAPI=5) alike. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBA4YUACgkQ2ugaI38ACPD96gD+Pu9f9SVG//0yhioO0LGP/W8o sIGpiMFIEddXvhUsDAwA/0EJkZF8jrN7zmt/LdZy3nlCGKTIkPNxp5ukUGDDWIJB =Dlem -END PGP SIGNATURE-
Re: [gentoo-dev] EJOBS variable for EAPI 5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 12:08 PM, Ian Stakenvicius wrote: On 31/08/12 11:27 AM, Alexandre Rostovtsev wrote: On Fri, 2012-08-31 at 15:45 +0100, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Coming back to this old topic [1]. Is there still consensus that we should have such an EJOBS variable? (It shouldn't be called JOBS because this name is too generic, see the old discussion.) Then we could add it to EAPI 5. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml If we're doing this, do we tell users to stop setting MAKEOPTS for EAPIs 5 and greater? Do we change the name of MAKEOPTS for EAPIs 5 and greater instead? Do we put fancy code in the package mangler to deal with it? Users typically set MAKEOPTS systemwide in /etc/make.conf. If EJOBS will have no effect for EAPI5 ebuilds, then obviously we should not be advising users to stop using MAKEOPTS until the whole tree has migrated to EAPI5. And if EJOBS will be recognized by a future version of portage for all EAPIs, then we still should allow MAKEOPTS because some users may want to use --load-average. Changing the name of MAKEOPTS in =EAPI5 makes no sense. First, because it's a standard environment variable used by gnu make. Second, because having 3 different settings for parallel building (EJOBS, MAKEOPTS, and MAKEOPTS_EAPI5) would be insane. Fancy code in the package manager would be the way to go IMHO. Ulrich's message contains a reasonable description of the algorithm. -Alexandre. I think, if i read the previous response to this correctly, that the suggestion isn't the removal of MAKEOPTS, but simply that the '-j' specification currently set in MAKEOPTS should instead be set in EJOBS in everyone's make.conf. This would then be appended to MAKEOPTS (for all EAPI) -and- be used for non-make build systems (for EAPI=5) alike. ..hit send to soon... So if users stick with setting -j in MAKEOPTS, then in EAPI=5 and above this would only affect make-based builds; for parallel compilation in non-make builds they would need to convert to using EJOBS for EAPI=5 and above, otherwise those build systems will compile serially instead of in parallel. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBA4jQACgkQ2ugaI38ACPAFrAEArp7MM5w4Mv/TLKb058HzB9oN NtQeSVoCQ8X5PuxjjJ0BAKbTJXEkLlZ0hMr09RyTKzK0XtdQq6cf2fbeFFgFb5eV =+vtW -END PGP SIGNATURE-
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On 31-08-2012 18:08:12 +0200, Michał Górny wrote: And for a reasonable Gentoo toolchain, pkg-config is a must-have. At least since we deprecated and are seriously fighting libtool. what? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 18:12:58 +0200 Fabian Groffen grob...@gentoo.org wrote: On 31-08-2012 18:08:12 +0200, Michał Górny wrote: And for a reasonable Gentoo toolchain, pkg-config is a must-have. At least since we deprecated and are seriously fighting libtool. what? Libtool archives, I meant. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 12:12 PM, Fabian Groffen wrote: On 31-08-2012 18:08:12 +0200, Michał Górny wrote: And for a reasonable Gentoo toolchain, pkg-config is a must-have. At least since we deprecated and are seriously fighting libtool. what? deprecated libtool = deprecated the installation of libtool's .la files unless absolutely necessary -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBA5YEACgkQ2ugaI38ACPBdKwD/VBUh3YujIN6gTAQD1NkWGij0 NHQbKrTeqTZV5i7S7IQBAJwCvgNuJgFRioAUMJrFfwQvNO7xEbt+hFXCtLM1zWtf =ognq -END PGP SIGNATURE-
[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
Michał Górny posted on Fri, 31 Aug 2012 18:08:12 +0200 as excerpted: Reducing @system may be a goal but it should be a *reasonable* goal. Not reducing because we can reduce but because it is bloated with unneeded software. We shouldn't even try to go below POSIX system requirements; we shouldn't remove standard Linux stuff (from Linux profiles, at least) either. And I believe toolchain belongs to @system as well; or at least the C99 compiler. And for a reasonable Gentoo toolchain, pkg-config is a must-have. At least since we deprecated and are seriously fighting libtool. I think I see the problem. Unsurprisingly it's a terminology definition mismatch problem, as so many are. =:^\ The reduce @system idea considers it a simple set of packages that are treated specially, and that exists to some degree for legacy reasons (back when gentoo was first being created, it was just easier to do it that way). The (obviously long-term) goal would be to eliminate @system with its currently special treatment entirely, including POSIX components. That may not be possible, but reducing it substantially should be. But we're not talking actually removing packages from a default gentoo install, just increasing the number of packages that are directly specified depends and removing them from the @system _set_, until there's very little if anything left to it. Thus, not adding it to @system in no way means it's not considered mandatory for a normal install, it just means the ultimate goal is to have all the deps specified and nothing left in @system, and while progress isn't fast by a long shot, the first thing is to ensure we're not regressing! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] x32 changing CHOST
On Fri, Aug 17, 2012 at 11:38 PM, Mike Frysinger wrote: people seem to be settling on x86_64-pc-linux-gnux32 as the default tuple, so i'll be updating our profiles to use that by default. this shouldn't impact anyone already running x32 as the existing tuple/ABI settings should continue to work just fine (no plans to ever change that). i've finally gotten around to pushing this. i did an in-place upgrade in my chroot and it worked fine. -mike
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, Aug 31, 2012 at 2:16 PM, Duncan 1i5t5.dun...@cox.net wrote: Thus, not adding it to @system in no way means it's not considered mandatory for a normal install, it just means the ultimate goal is to have all the deps specified and nothing left in @system, and while progress isn't fast by a long shot, the first thing is to ensure we're not regressing! If the ultimate goal is to eliminate @system entirely (which it probably isn't), we will need to revisit the way stage building works. If understand correctly, a stage3 contains @system and its dependencies. The smallest you can really make @system under that circumstance would be a working toolchain and the utilities necessary to build any other needed packages. I think that is the goal that most people have been shooting for lately.
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 14:56:06 -0400 Mike Gilbert flop...@gentoo.org wrote: On Fri, Aug 31, 2012 at 2:16 PM, Duncan 1i5t5.dun...@cox.net wrote: Thus, not adding it to @system in no way means it's not considered mandatory for a normal install, it just means the ultimate goal is to have all the deps specified and nothing left in @system, and while progress isn't fast by a long shot, the first thing is to ensure we're not regressing! If the ultimate goal is to eliminate @system entirely (which it probably isn't), we will need to revisit the way stage building works. If understand correctly, a stage3 contains @system and its dependencies. The smallest you can really make @system under that circumstance would be a working toolchain and the utilities necessary to build any other needed packages. I think that is the goal that most people have been shooting for lately. But you are aware that this will practically mean that there could be no stand-alone ebuild repository because fulfilling the ebuild dependencies wouldn't be anymore possible without providing all of the standard system components, including those specified as required by the PMS? That in turn will make PMS utility requirements (bash, GNU find etcetera) completely useless because the ebuilds will have to request them explicitly anyway. But hey, you're aware that ebuilds use some of those tools in global scope, before DEPEND is fulfilled? Also, I don't think we have any kind of 'build'-time dependencies for binary packages... -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] The Recruiters Project is looking for new members
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Good evening everyone, It is again this time of year where the Recruiters project[1] is seeking more manpower. We are looking for a maximum of two people to join this project as soon as possible. The ideal candidates must be developers for more than a year and they should also be fairly familiar with ebuild writing and the Gentoo policies overall. Also, *plenty* of free time it is an absolute requirement. If you are interested, please contact us at recruiters_at_gentoo_dot_org. [1]: http://www.gentoo.org/proj/en/devrel/recruiters/ - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJQQQw2AAoJEPqDWhW0r/LCSOcQAJq/I8aZRNWKBzlN3SUQ6BXZ fouHtPjpc4ImtjMF0dz5yejnZjuudMbiJUWDYeWcV4eMwvcbNJbptSIHatVp1r/2 MOfQbTT5sCuhYGy6thHsgoaM3Kgyx1s0vcf1UrhY4cQ54ZCFnvCWy865cyaaki7C IwSEXS1GBmFVtfv0iuL52c87fSYujexL5wQMmh1XQ4lkRcim4wQ14Eq1kuA+DUT6 bLMVYIskQqmEr4YSpo2KaTYcvQRfAks00c4i8pVVVnv5OHTd78AASXJHLEklh7Ua oroXruqaSsReSdjdXwVcjK7JWYmcIeVw6OY/Zp2IthAuHnLdYBheDRQiayGz7lJe AMy8a9UkHyU5lsEugmVoBcPAew+bZfk6sYgWOlvWGM917bjlVpyRqdQTs7QpOAbb NUvNNU3qxiAXUaIMPmRMC2QArBd1aMlBoeuiXSrEH9Ki5ejS5hfP5b+7nz00qzQX /g7ERrkshYnKnwVHt+rjZO9+Q6guB3g1StsCZFR405OCUVLYCOt/6M0r6/rcSPAK LSXkjshz8wTM6jSABAsO8CGsFkfyxzIPhWuwPNP7crfAweMx3mtuYv00RJo4XvDH OZb5MSuQ508jml3SofV/Etp5DRRMI2f8/ydp2Kdhh2q3nYIGU7Pvluv4xBKfSEYg FPZvOsWS18MdVfqKyOC5 =IAV6 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 18:03:33 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 31 Aug 2012 11:05:23 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 10:56 AM, Alexis Ballier wrote: Michał Górny mgo...@gentoo.org wrote: I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically And realistically that's where the DEPEND should be anyways, IMO -- appended by the eclass where the function is that uses it. If this means prune_libtool_files() gets separated out of eutils and put in its own eclass (so that all the eutils inheritors don't suddenly need virtual/pkgconfig unnecessarily), then so be it. I wasn't referring to the function at the moment but at the overall fact that practically any C/C++ package depending on any non-standard library practically should depend on pkg-config. A library not providing pkg-config file is simply broken. Hu? You know, some people think pkgconfig is a poorman's workaround for a different problem. You don't need .pc files for dynamic linking because: 1) there is a standard include search path 2) there is a standard library path 3) elf shared objects support dependencies You might need pkgconfig for static linking because static archives do not support 3). Isn't it the thing that should be improved instead ? Alike you claim a library not providing a .pc is broken, I can claim that a library relying on it is broken because it is violating 1) and/or 2) which are well established unix behavior. A.
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert flop...@gentoo.org wrote: On Fri, Aug 31, 2012 at 2:16 PM, Duncan 1i5t5.dun...@cox.net wrote: Thus, not adding it to @system in no way means it's not considered mandatory for a normal install, it just means the ultimate goal is to have all the deps specified and nothing left in @system, and while progress isn't fast by a long shot, the first thing is to ensure we're not regressing! If the ultimate goal is to eliminate @system entirely (which it probably isn't), we will need to revisit the way stage building works. If understand correctly, a stage3 contains @system and its dependencies. The goal would be to eliminate @system entirely. The solution to stage3 would be to have a set like @system of default starting packages. It might even be a defined set that users could make use of (emerge @default), but ebuilds could not assume that they are present. To build them you just start with a working Gentoo system and emerge them. The smallest you can really make @system under that circumstance would be a working toolchain and the utilities necessary to build any other needed packages. I think that is the goal that most people have been shooting for lately. Nobody is suggesting that a system containing no packages whatsoever should be bootable, let alone usable to bootstrap everything else. There would be some minimal set of packages needed to bootstrap the rest. However, ebuilds would need to explicitly declare their need for them rather than assuming they are present. Virtuals could be used to simplify this. In fact, there is a simple way to transition to such a system. Start by defining a virtual that contains everything that is in @system (setting aside the issue that this is profile-dependent), and adding that as a DEPEND and RDEPEND to every ebuild. Then start paring it down per-ebuild. The goal is not to have working Gentoo systems that contain nothing on their hard drives, but rather to eliminate the arbitrary collection of packages that must be present everywhere, because some software that might or might not even be installed could need them. Rich
[gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
For those who may not know, chromium-os currently uses a hard-host-depends ebuild as a workaround for our lack of HDEPEND support [1]. We could easily add HDEPEND in EAPI 5 if we want, since we already have a Portage patch attached to bug #317337 [2]. Here is a summary of what that Portage patch will do: In EAPI 5 or later, DEPEND has been divided into two parts: DEPEND for build-time target dependencies, and HDEPEND for build-time host dependencies. This division is designed specifically to minimize difficulty in the process of adapting ebuilds that were written for earlier EAPIs, and therefore it also minimizes the adjustments that ebuild developers will have to make to the thought processes involved when writing ebuilds from scratch. In an environment that does not involve cross-compilation, HDEPEND behaves the same as DEPEND. When an ebuild is converted from EAPI 4 or earlier to EAPI 5 or later, in order to support cross-compilation environments, some dependencies may need to be migrated to HDEPEND. For ebuilds that have EAPI 5 or later, the emerge --root-deps option has no effect since it is made obsolete by division between DEPEND and HDEPEND. If EAPI 4 or earlier ebuilds are used in combination with EAPI 5 or later ebuilds, the --root-deps behavior will still be applied to the EAPI 4 or earlier ebuilds (there is no behavior change for ebuilds having older EAPIs). [1] http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq [2] https://bugs.gentoo.org/show_bug.cgi?id=317337 -- Thanks, Zac
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 08/31/2012 04:03 PM, Zac Medico wrote: For those who may not know, chromium-os currently uses a hard-host-depends ebuild as a workaround for our lack of HDEPEND support [1]. We could easily add HDEPEND in EAPI 5 if we want, since we already have a Portage patch attached to bug #317337 [2]. Here is a summary of what that Portage patch will do: In EAPI 5 or later, DEPEND has been divided into two parts: DEPEND for build-time target dependencies, and HDEPEND for build-time host dependencies. This division is designed specifically to minimize difficulty in the process of adapting ebuilds that were written for earlier EAPIs, and therefore it also minimizes the adjustments that ebuild developers will have to make to the thought processes involved when writing ebuilds from scratch. In an environment that does not involve cross-compilation, HDEPEND behaves the same as DEPEND. When an ebuild is converted from EAPI 4 or earlier to EAPI 5 or later, in order to support cross-compilation environments, some dependencies may need to be migrated to HDEPEND. For ebuilds that have EAPI 5 or later, the emerge --root-deps option has no effect since it is made obsolete by division between DEPEND and HDEPEND. If EAPI 4 or earlier ebuilds are used in combination with EAPI 5 or later ebuilds, the --root-deps behavior will still be applied to the EAPI 4 or earlier ebuilds (there is no behavior change for ebuilds having older EAPIs). [1] http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq [2] https://bugs.gentoo.org/show_bug.cgi?id=317337 I like this. It has my support. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 13:03:00 -0700 Zac Medico zmed...@gentoo.org wrote: For those who may not know, chromium-os currently uses a hard-host-depends ebuild as a workaround for our lack of HDEPEND support [1]. We could easily add HDEPEND in EAPI 5 if we want, since we already have a Portage patch attached to bug #317337 [2]. Here is a summary of what that Portage patch will do: In EAPI 5 or later, DEPEND has been divided into two parts: DEPEND for build-time target dependencies, and HDEPEND for build-time host dependencies. This division is designed specifically to minimize difficulty in the process of adapting ebuilds that were written for earlier EAPIs, and therefore it also minimizes the adjustments that ebuild developers will have to make to the thought processes involved when writing ebuilds from scratch. In an environment that does not involve cross-compilation, HDEPEND behaves the same as DEPEND. When an ebuild is converted from EAPI 4 or earlier to EAPI 5 or later, in order to support cross-compilation environments, some dependencies may need to be migrated to HDEPEND. For ebuilds that have EAPI 5 or later, the emerge --root-deps option has no effect since it is made obsolete by division between DEPEND and HDEPEND. If EAPI 4 or earlier ebuilds are used in combination with EAPI 5 or later ebuilds, the --root-deps behavior will still be applied to the EAPI 4 or earlier ebuilds (there is no behavior change for ebuilds having older EAPIs). What exactly would the rules be for handling a package that is in both DEPEND and HDEPEND, when ROOT is in effect? Would the versions be expected to match? What about use flags? 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 16:01:01 -0400 Rich Freeman ri...@gentoo.org wrote: On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert flop...@gentoo.org wrote: On Fri, Aug 31, 2012 at 2:16 PM, Duncan 1i5t5.dun...@cox.net wrote: Thus, not adding it to @system in no way means it's not considered mandatory for a normal install, it just means the ultimate goal is to have all the deps specified and nothing left in @system, and while progress isn't fast by a long shot, the first thing is to ensure we're not regressing! If the ultimate goal is to eliminate @system entirely (which it probably isn't), we will need to revisit the way stage building works. If understand correctly, a stage3 contains @system and its dependencies. The goal would be to eliminate @system entirely. The solution to stage3 would be to have a set like @system of default starting packages. It might even be a defined set that users could make use of (emerge @default), but ebuilds could not assume that they are present. To build them you just start with a working Gentoo system and emerge them. The smallest you can really make @system under that circumstance would be a working toolchain and the utilities necessary to build any other needed packages. I think that is the goal that most people have been shooting for lately. Nobody is suggesting that a system containing no packages whatsoever should be bootable, let alone usable to bootstrap everything else. There would be some minimal set of packages needed to bootstrap the rest. However, ebuilds would need to explicitly declare their need for them rather than assuming they are present. Virtuals could be used to simplify this. In fact, there is a simple way to transition to such a system. Start by defining a virtual that contains everything that is in @system (setting aside the issue that this is profile-dependent), and adding that as a DEPEND and RDEPEND to every ebuild. Then start paring it down per-ebuild. The goal is not to have working Gentoo systems that contain nothing on their hard drives, but rather to eliminate the arbitrary collection of packages that must be present everywhere, because some software that might or might not even be installed could need them. That arbitrary collection of packages is called a system. I don't think the goal for Gentoo should be to abandon standards like POSIX in favor of 'design system yourself but don't come crying to us if you forget some vital component which will make your system unbootable'. Such a goals may be good for distributions like Exherbo which aim to make everything perfect. I believe that Gentoo aims more around 'good enough but at least realistic', instead of running for some kind of utopia which simply does not work. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 15:31:43 -0400 Alexis Ballier aball...@gentoo.org wrote: On Fri, 31 Aug 2012 18:03:33 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 31 Aug 2012 11:05:23 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 10:56 AM, Alexis Ballier wrote: Michał Górny mgo...@gentoo.org wrote: I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically And realistically that's where the DEPEND should be anyways, IMO -- appended by the eclass where the function is that uses it. If this means prune_libtool_files() gets separated out of eutils and put in its own eclass (so that all the eutils inheritors don't suddenly need virtual/pkgconfig unnecessarily), then so be it. I wasn't referring to the function at the moment but at the overall fact that practically any C/C++ package depending on any non-standard library practically should depend on pkg-config. A library not providing pkg-config file is simply broken. Hu? You know, some people think pkgconfig is a poorman's workaround for a different problem. You don't need .pc files for dynamic linking because: 1) there is a standard include search path 2) there is a standard library path 3) elf shared objects support dependencies You might need pkgconfig for static linking because static archives do not support 3). Isn't it the thing that should be improved instead ? Alike you claim a library not providing a .pc is broken, I can claim that a library relying on it is broken because it is violating 1) and/or 2) which are well established unix behavior. I'm not sure if you're aware of it but Gentoo doesn't aim at supporting solely Linux and no other system. Also, please tell me how to handle multiple slots sanely without pkg-config in a package like Boost, for example. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 08/31/2012 01:46 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 13:03:00 -0700 What exactly would the rules be for handling a package that is in both DEPEND and HDEPEND, when ROOT is in effect? Would the versions be expected to match? What about use flags? For the sake of simplicity, I would treat them as entirely independent. It should be easy enough for users to apply manual configuration adjustments in order to resolve any conflicts of this nature that may arise. If there turns out to be a strong demand for additional constraints, we can consider adding them in a future EAPI (possibly using a combined DEPENDENCIES variable). 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, Well, I not sure that major changes is a really good characterization. We're just talking about migrating a few things from DEPEND to HDEPEND, and it's not strictly required. The migration is only needed when fulfilling a request to support cross-compilation in a particular ebuild. 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. -- Thanks, Zac
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
I like this as well. However, since we're going to introduce a *DEPEND split, how about splitting PDEPEND as well? As far as I've seen, PDEPEND has two (or more?) different meanings: - advisory (for instance, informing users about plugins) - cycle-breaking to help the dependency solver Would it be possible to add support for ODEPEND (as in optional dependencies -- I don't really care about the variable name) as well? This would be quite beneficial under certain circumstances. One of these is when ebuilds are shipped with PDEPENDs which are not required at runtime nor for cycle-breaking... Another scenario in where ODEPEND would be nice to have is with systemd init files pulled in by USE=systemd (and generally use? ( sys-apps/systemd ) in *DEPEND). Providing full systemd support for all the packages without forcing users to have it installed, given that openrc is the de-facto standard init system in Gentoo (and we don't have any openrc? ( sys-apps/openrc )), would be a nice features for binpkg repos. Users could then choose to enable or disable ODEPEND during dependencies calculation via make.conf or argv. I don't want to diverge too much from the HDEPEND discussion, but I think that if we're going to split *DEPEND, it might be a good opportunity to do it right _once_ and _for all_. -- Fabio Erculiani
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 22:53:35 +0200 Michał Górny mgo...@gentoo.org wrote: [...] I'm not sure if you're aware of it but Gentoo doesn't aim at supporting solely Linux and no other system. elf != linux Also, please tell me how to handle multiple slots sanely without pkg-config in a package like Boost, for example. You should know since you are proposing a boost-utils.eclass :) Anyway, my point was just to go from 'not providing a .pc is broken' to '.pc are useful and needed in some cases but not all' A.
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 23:40:27 +0200 Fabio Erculiani lx...@gentoo.org wrote: Would it be possible to add support for ODEPEND (as in optional dependencies -- I don't really care about the variable name) as well? This would be quite beneficial under certain circumstances. One of these is when ebuilds are shipped with PDEPENDs which are not required at runtime nor for cycle-breaking... This is what we call suggestions and SDEPEND. There are already two proposals for dealing with this general issue. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 14:11:38 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/31/2012 01:46 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 13:03:00 -0700 What exactly would the rules be for handling a package that is in both DEPEND and HDEPEND, when ROOT is in effect? Would the versions be expected to match? What about use flags? For the sake of simplicity, I would treat them as entirely independent. It should be easy enough for users to apply manual configuration adjustments in order to resolve any conflicts of this nature that may arise. If there turns out to be a strong demand for additional constraints, we can consider adding them in a future EAPI (possibly using a combined DEPENDENCIES variable). The thing is... Without some kind of the same constraint, we'd be adding a feature which would probably work most of the time only by coincidence. 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, Well, I not sure that major changes is a really good characterization. We're just talking about migrating a few things from DEPEND to HDEPEND, and it's not strictly required. The migration is only needed when fulfilling a request to support cross-compilation in a particular ebuild. Where are you getting a few from? Is this a few seems to be enough to make it work, or someone carefully analysed lots of packages to work out exactly what dependencies are HDEPEND, and measured it? I strongly suspect we're in works by coincidence territory again -- adding packages to HDEPEND as breakages are encountered is a long way from having an accurate HDEPEND. Are we aiming for the former or the latter? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 08/31/2012 02:40 PM, Fabio Erculiani wrote: I like this as well. However, since we're going to introduce a *DEPEND split, how about splitting PDEPEND as well? As far as I've seen, PDEPEND has two (or more?) different meanings: - advisory (for instance, informing users about plugins) - cycle-breaking to help the dependency solver Would it be possible to add support for ODEPEND (as in optional dependencies -- I don't really care about the variable name) as well? This would be quite beneficial under certain circumstances. One of these is when ebuilds are shipped with PDEPENDs which are not required at runtime nor for cycle-breaking... Another scenario in where ODEPEND would be nice to have is with systemd init files pulled in by USE=systemd (and generally use? ( sys-apps/systemd ) in *DEPEND). Providing full systemd support for all the packages without forcing users to have it installed, given that openrc is the de-facto standard init system in Gentoo (and we don't have any openrc? ( sys-apps/openrc )), would be a nice features for binpkg repos. Users could then choose to enable or disable ODEPEND during dependencies calculation via make.conf or argv. I don't want to diverge too much from the HDEPEND discussion, but I think that if we're going to split *DEPEND, it might be a good opportunity to do it right _once_ and _for all_. For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 -- Thanks, Zac
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 08/31/2012 02:53 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 14:11:38 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/31/2012 01:46 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 13:03:00 -0700 What exactly would the rules be for handling a package that is in both DEPEND and HDEPEND, when ROOT is in effect? Would the versions be expected to match? What about use flags? For the sake of simplicity, I would treat them as entirely independent. It should be easy enough for users to apply manual configuration adjustments in order to resolve any conflicts of this nature that may arise. If there turns out to be a strong demand for additional constraints, we can consider adding them in a future EAPI (possibly using a combined DEPENDENCIES variable). The thing is... Without some kind of the same constraint, we'd be adding a feature which would probably work most of the time only by coincidence. Shrug, I don't do any cross-compilation myself, but maybe someone who does could comment on the usefulness of this kind of constraint. Mike? Brian? 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, Well, I not sure that major changes is a really good characterization. We're just talking about migrating a few things from DEPEND to HDEPEND, and it's not strictly required. The migration is only needed when fulfilling a request to support cross-compilation in a particular ebuild. Where are you getting a few from? Is this a few seems to be enough to make it work, or someone carefully analysed lots of packages to work out exactly what dependencies are HDEPEND, and measured it? I strongly suspect we're in works by coincidence territory again -- adding packages to HDEPEND as breakages are encountered is a long way from having an accurate HDEPEND. Are we aiming for the former or the latter? I would think of it like prefix support in EAPI 3. Ebuilds using EAPI 3 were not required to support prefix. Similarly, ebuilds using EAPI 5 will not be required to support cross-compilation. -- Thanks, Zac
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 14:58:49 -0700 Zac Medico zmed...@gentoo.org wrote: For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 Do we have an implementation of this yet? I have extreme doubts about the viability of the idea... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, Aug 31, 2012 at 11:58 PM, Zac Medico zmed...@gentoo.org wrote: For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. I think SDEPEND is a much simpler approach to the issue, why introducing a new kind of USE flags to address what really belongs to *DEPEND? -- Thanks, Zac -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 08/31/2012 03:15 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 14:58:49 -0700 Zac Medico zmed...@gentoo.org wrote: For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 Do we have an implementation of this yet? I have extreme doubts about the viability of the idea... No, but there's a request here: https://bugs.gentoo.org/show_bug.cgi?id=424283 -- Thanks, Zac
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Sat, 1 Sep 2012 00:18:07 +0200 Fabio Erculiani lx...@gentoo.org wrote: On Fri, Aug 31, 2012 at 11:58 PM, Zac Medico zmed...@gentoo.org wrote: For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. I think SDEPEND is a much simpler approach to the issue, why introducing a new kind of USE flags to address what really belongs to *DEPEND? Because otherwise you can't use USE flags. The rationale is there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 14:58:49 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/31/2012 02:40 PM, Fabio Erculiani wrote: I like this as well. However, since we're going to introduce a *DEPEND split, how about splitting PDEPEND as well? As far as I've seen, PDEPEND has two (or more?) different meanings: - advisory (for instance, informing users about plugins) - cycle-breaking to help the dependency solver Would it be possible to add support for ODEPEND (as in optional dependencies -- I don't really care about the variable name) as well? This would be quite beneficial under certain circumstances. One of these is when ebuilds are shipped with PDEPENDs which are not required at runtime nor for cycle-breaking... Another scenario in where ODEPEND would be nice to have is with systemd init files pulled in by USE=systemd (and generally use? ( sys-apps/systemd ) in *DEPEND). Providing full systemd support for all the packages without forcing users to have it installed, given that openrc is the de-facto standard init system in Gentoo (and we don't have any openrc? ( sys-apps/openrc )), would be a nice features for binpkg repos. Users could then choose to enable or disable ODEPEND during dependencies calculation via make.conf or argv. I don't want to diverge too much from the HDEPEND discussion, but I think that if we're going to split *DEPEND, it might be a good opportunity to do it right _once_ and _for all_. For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 The canonical URI is: http://www.gentoo.org/proj/en/glep/glep-0062.html -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 08/31/2012 03:18 PM, Fabio Erculiani wrote: On Fri, Aug 31, 2012 at 11:58 PM, Zac Medico zmed...@gentoo.org wrote: For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. All suggested deps are not equal, so USE flags give you the ability to pick and choose the ones that you want. I think SDEPEND is a much simpler approach to the issue, why introducing a new kind of USE flags to address what really belongs to *DEPEND? I guess we could combine the two ideas if we allow USE conditionals inside SDEPEND. -- Thanks, Zac
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 17:49:34 -0400 Alexis Ballier aball...@gentoo.org wrote: On Fri, 31 Aug 2012 22:53:35 +0200 Michał Górny mgo...@gentoo.org wrote: [...] I'm not sure if you're aware of it but Gentoo doesn't aim at supporting solely Linux and no other system. elf != linux Gentoo != elf only. Also, please tell me how to handle multiple slots sanely without pkg-config in a package like Boost, for example. You should know since you are proposing a boost-utils.eclass :) Eh, the world would be so much better if boost provided pkg-config files. For example, boost.m4 (provided by boost-m4) uses some wall-dumb stubborn heuristics which always grabs newest boost and doesn't provide any sane way to provide it with an older one... Anyway, my point was just to go from 'not providing a .pc is broken' to '.pc are useful and needed in some cases but not all' But these some cases where there are needed result in the necessity of installing them, and making the build systems aware of them. I don't see much point in adding a 'backwards compatibility' to it as well. Ah, while we're at it. If a library has macros referring to the functions of another library (or just types) in its public API, it needs a pkg-config file. ELF dependencies are not enough, and the gold linker will refuse to work because of a missing explicit dependency. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 16:03:25 -0700 Zac Medico zmed...@gentoo.org wrote: runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. All suggested deps are not equal, so USE flags give you the ability to pick and choose the ones that you want. So does --take / --ignore with suggested dependencies, with the added advantage that suggested packages don't end up being brought in without user request just because a user has a particular use flag enabled globally. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, 31 Aug 2012 16:03:25 -0700 Zac Medico zmed...@gentoo.org wrote: I think SDEPEND is a much simpler approach to the issue, why introducing a new kind of USE flags to address what really belongs to *DEPEND? I guess we could combine the two ideas if we allow USE conditionals inside SDEPEND. But you don't want to do that... The point of suggestions is that they can be considered on their own merits. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On 8/31/2012 4:48 AM, Rich Freeman wrote: On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny mgo...@gentoo.org wrote: So please introduce virtual/compiler, virtual/linker, virtual/posix-system, virtual/sratatata and add them to DEPEND of every single ebuild. Every ebuild doesn't need all of those - that is the whole point. As Duncan already pointed out, reducing @system is a goal, but it doesn't mean that we need to get there overnight. However, we'll never get there if we keep going backwards. My 2c on this: I'm reluctant to make sweeping statements like this, for any number of reasons, but -- well, I'm gonna. IMO, getting there by slow evolution is not the right way. At some point, @system becomes so primitive that bootstrapping must come to depend on more than @system, or we have to add add more phases to the bootstrap process, or split @system up into smaller sets or something. The point is, we can't gradually reach a goal that's incompatible with the fundamental premise. It's all well and good to say let's not put more stuff into @system because we want it to shrink, but, as it stands, there's a de-facto policy that @system includes everything needed to have a reasonably functional Gentoo, including all of the compilers, development tools and interpreters portage, gcc, and your rc system of choice rely on. Until that fundamentally changes, IMO what belongs in @system is whatever best suits its current purpose. For the record, I'm not saying we need to put pkgconfig in - I'm totally agnostic about that, as I am about whether it should be brought in as a dependency. I just mean, probably the best way to fix the fat-@system problem is to create some kind of vision for a more-modular Gentoo of the Future first, and create a roadmap for getting there, second. Its possible, perhaps even likely, that if we try to go the incremental route towards @system reduction, we will find, along the way, creative solutions to the various issues that have kept it fat-ish so far. But that's likely to lead to a fairly ad-hoc patchwork of hacks, which imo would most likely be inferior to what could be achieved with some kind of destination in mind (even if that destination is subject to major revision as Gentoo progress toward it). -gmt
[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
Gregory M. Turner posted on Fri, 31 Aug 2012 16:13:20 -0700 as excerpted: For the record, I'm not saying we need to put pkgconfig in - I'm totally agnostic about that, as I am about whether it should be brought in as a dependency. [Just replying here as it's handy.] I don't believe the following bit has been explicitly stated yet. I'm not sure if it's sufficiently implicit that it doesn't need stated for not, but in case it helps: The effect of adding pkgconfig to @system is just this: Currently, we have an explicit list of all packages that need it (barring missing dependency bugs, of course). If it gets added to @system, that list immediately gets decimated, and while its historical value can always be dug out of the VCS (as long as the git upgrade or whatever doesn't lose that information, anyway), it's no longer being updated and will quickly go stale, so when the time comes and we DO decide to finally seriously tackle @system removal, that's one more dependency that we have to go to (excuse the shouting) ALL THE WORK OF RECREATING THE DATA WE CURRENTLY HAVE, ALL OVER AGAIN. We have that data for pkgconfig now, and currently, it must be maintained in at least a semi-reasonable state. If we ever DO get serious about @system removal, we'll definitely need that data. So let's not go voluntarily dumping it down the toilet, which is what adding pkgconfig to @system would amount to, only to decide we actually need that data after all, but by then it'll be gone, so we'll have to recreate it from scratch. That's what all this is about, not adding yet another package to the list of packages we don't HAVE proper dependency data for, data that we'll have to create from scratch if we ever do decide to move on the @system removal thing, when for this package at least, we already HAD it, and will have deliberately thrown it away by adding the package to @system. If it was as simple as just adding it to the list, and we weren't throwing away a quite valuable bunch of already accumulated dependency data as a result, sure, no problem, go right ahead. Unfortunately... -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Sat, 1 Sep 2012 01:05:39 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 31 Aug 2012 17:49:34 -0400 Alexis Ballier aball...@gentoo.org wrote: On Fri, 31 Aug 2012 22:53:35 +0200 Michał Górny mgo...@gentoo.org wrote: [...] I'm not sure if you're aware of it but Gentoo doesn't aim at supporting solely Linux and no other system. elf != linux Gentoo != elf only. Prefix? Come on, some usecases do not make pkgconfig so vital for every gentoo install that it should be in @system. Also, please tell me how to handle multiple slots sanely without pkg-config in a package like Boost, for example. You should know since you are proposing a boost-utils.eclass :) Eh, the world would be so much better if boost provided pkg-config files. For example, boost.m4 (provided by boost-m4) uses some wall-dumb stubborn heuristics which always grabs newest boost and doesn't provide any sane way to provide it with an older one... Yes, pkgconfig can be useful, sometimes... Anyway, my point was just to go from 'not providing a .pc is broken' to '.pc are useful and needed in some cases but not all' But these some cases where there are needed result in the necessity of installing them, and making the build systems aware of them. I don't see much point in adding a 'backwards compatibility' to it as well. If the build system needs pkgconfig then the ebuild should depend on it, whats wrong with that ? I dont need pkgconfig to run the package after its built. For the same reason people have been working to _remove_ flex, m4, bison, autoconf, automake from @system, pkgconfig does not belong there either... Ah, while we're at it. If a library has macros referring to the functions of another library (or just types) in its public API, it needs a pkg-config file. ELF dependencies are not enough, and the gold linker will refuse to work because of a missing explicit dependency. Eh, straight to the point where pkgconfig is not the solution to everything: a binary not using said macros but trusting pkgconfig will get overlinked. Documentation stating that when using these macros/functions one should link to the other lib would make things even better. A.
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On 08/31/2012 04:07 PM, Ciaran McCreesh wrote: On Fri, 31 Aug 2012 16:03:25 -0700 Zac Medico zmed...@gentoo.org wrote: runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. All suggested deps are not equal, so USE flags give you the ability to pick and choose the ones that you want. So does --take / --ignore with suggested dependencies, with the added advantage that suggested packages don't end up being brought in without user request just because a user has a particular use flag enabled globally. If the USE flags have ambiguous meanings doesn't that mean that they've been poorly named? -- Thanks, Zac
[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 22:51:08 +0200 Michał Górny mgo...@gentoo.org wrote: That arbitrary collection of packages is called a system. I don't think the goal for Gentoo should be to abandon standards like POSIX in favor of 'design system yourself but don't come crying to us if you forget some vital component which will make your system unbootable'. Gentoo is actually an old Navaho word meaning some assembly required, batteries not included. You thought it was a penguin? Such a goals may be good for distributions like Exherbo which aim to make everything perfect. I believe that Gentoo aims more around 'good enough but at least realistic', instead of running for some kind of utopia which simply does not work. I don't understand your stance here, because to me 'good enough but realistic' means ignoring standards when they're stupid, embracing them when they're not, and forging your own where they don't yet exist. Perfection, by definition, requires an existing standard to hold yourself up against. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
