Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. The good solutions should not be made ugly to support corner cases. -- this really starts to resemble multilib portage :) I've said already that multilib is a thing which could be done by eclasses and doesn't need making PM scary. And Tommy says that multilib-portage handles packages having IUSE=multilib fine. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggest to specify a way to query for USEs in next council
El sáb, 22-09-2012 a las 22:37 +0200, Michał Górny escribió:
On Sat, 22 Sep 2012 21:41:24 +0200
Pacho Ramos pa...@gentoo.org wrote:
Hello
This comes from:
http://www.gossamer-threads.com/lists/gentoo/dev/260536
In that one, we try to use the following:
has vala ${IUSE//+/} ! use vala return 0
Just please stop repeating the random broken snippet and use `in_iuse`
from eutils.eclass. That one is correct at least.
Sorry, I forget about it when I sent the message (was thinking most on
specifying the way to catch USEs by PMs and I referred to the command
used in some eclasses). Obviously, I would try to use function from
eutils.eclass :)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] media-video/vlc looking for a new maintainer
On 09/19/2012 04:00 PM, Ben de Groot wrote: Thanks for all you have done maintaining VLC all those years. It is undoubtedly one of the most popular and versatile video players out there. I really hope someone steps up to become its new dedicated maintainer. Given I'm in contact with upstream I might cover the interim since a release is impelling, I prefer shared maintainership though. lu
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. - -1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQXt4ZAAoJEFpvPKfnPDWzuaUH/0EfL7BxiHQo+E1KvUHNrqlX YD1bt5c/TU82XMAQ4axqYDXSYHE8o/WYJPNFJy2ZZhseFlG1lOo9DxOd+zVIf7JE JqbIWbgJ6r+POKWREDTH8ZWQaq3r1G4BeOH7IbxwuGrLmTUp36oSpVRYX5XnXyl0 3MvRe9bXpih8exwOJudncc/4NFtX9c12wO6CifH0xKwcr7lu7k6jpRyfD3dIpXXq QQlY4MjuCfy6aHxp+4+CvL9WEZ4cmkXxoi/EZCsMZYb+jBQ1NF0Jxr6tULX575vz Vvm+n3sdTPMkh863vrAmglwFYtDgucmp/OeYZD03g3Ef52x1/NefkIGcwXGUjlY= =FXgk -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 12:02:01 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. How is it stronger? By doing implicit magic on every ebuild? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Clarify the as-is license?
From time to time cases like the following are brought up to licen...@gentoo.org, for a package that is labelled with LICENSE=as-is: | Permission to use, copy, modify and/or distribute this software in | both binary and source form, for non-commercial purposes, is hereby | granted [...] This is clearly not free/open-source software because of the non-commercial restriction. In my understanding, our as-is really is what opensource.org lists as Historical Permission Notice and Disclaimer [1]. Obviously it's very permissive (comparable to MIT or BSD-2). It is also included in our @OSI-APPROVED license group. So, either we should only mark free software with the as-is label. Then it might help if the text was clarified as in the patch below. Or we continue marking random non-free stuff with as-is. Then we should IMHO remove as-is from our free license groups, create a licenses/HPND file (text as in [1]), and move the free packages to it. Currently, 679 packages have as-is in their LICENSE. Ulrich [1] http://opensource.org/licenses/HPND --- as-is 12 Jan 2012 19:03:23 - 1.3 +++ as-is 23 Sep 2012 09:43:19 - @@ -1,5 +1,5 @@ -This is a generic place holder for a class of licenses that boil down to do -no guarantees and all you get is what you have. The language is usually +This is a generic place holder for a class of licenses that allow you to +do most anything you want with the software. The language is usually similar to: Permission to use, copy, modify, and distribute this software and its @@ -12,13 +12,11 @@ suitability of this software for any purpose. It is provided as is without express or implied warranty. - -You will need to check the license that came with the software for the exact -specifics. Generally you are free to do most anything you want with as is -software but you should not take this license as legal advice. +You will need to check the license that came with the software (usually as +permission notice in the source files themselves) for the exact wording. Note: Most all license have an as is clause. For our purposes this does -not make all software in this category. This category is for software with -very little restrictions. +not make all software in this category. This category is for software that +complies with the Open Source Definition and has very little restrictions. The information in this license about licenses is presented as is. :-P
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. Looks interesting, yes, it uses cmake. I guess we would need to move all packages needing 32bits libs to this eclasses. Are you sure wouldn't be better to try to go to an upper level like Alexis Ballier suggested some messages ago?: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? -- this really starts to resemble multilib portage :) That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 13:03:56 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. Looks interesting, yes, it uses cmake. I guess we would need to move all packages needing 32bits libs to this eclasses. Are you sure wouldn't be better to try to go to an upper level like Alexis Ballier suggested some messages ago?: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? -- this really starts to resemble multilib portage :) That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) You could fix those ebuilds to inherit it too ;). autotools-utils was especially designed to use out-of-source builds for multilib in the future. I'm afraid the 'upper level' is technically impossible without either going into PM itself (which means waiting for EAPI 6 at least and getting some scary logic into it) or reinventing the phases alike ruby-ng/python-distutils-ng. Well, the latter may be useful to some degree; still, it would require each ebuild to redefine all phases. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Clarify the as-is license?
On Sun, Sep 23, 2012 at 6:56 AM, Ulrich Mueller u...@gentoo.org wrote: So, either we should only mark free software with the as-is label. Then it might help if the text was clarified as in the patch below. Or we continue marking random non-free stuff with as-is. Then we should IMHO remove as-is from our free license groups, create a licenses/HPND file (text as in [1]), and move the free packages to it. Well, I can see legal problems any time you take a thousand things that all have a bunch of non-identical, informal licenses and treat them as the same. However, I don't think it is practical to do otherwise. How about having an as-is-free and an as-is-nonfree. The easier thing on maintainers is to make one of those just as-is, and if we want to make sure we check them all the better thing is to not do that. However, making a new as-is-free and treating anything as-is as not free is probably good enough. I don't think it is wise to do the reverse, even though that involves the least amount of work. Rich
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 13:03:56 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. Looks interesting, yes, it uses cmake. I guess we would need to move all packages needing 32bits libs to this eclasses. Are you sure wouldn't be better to try to go to an upper level like Alexis Ballier suggested some messages ago?: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? -- this really starts to resemble multilib portage :) That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) You could fix those ebuilds to inherit it too ;). autotools-utils was especially designed to use out-of-source builds for multilib in the future. I'm afraid the 'upper level' is technically impossible without either going into PM itself (which means waiting for EAPI 6 at least and getting some scary logic into it) or reinventing the phases alike ruby-ng/python-distutils-ng. Well, the latter may be useful to some degree; still, it would require each ebuild to redefine all phases. Then, I think that main blocker to use autotools-utils.eclass more widely is that it needs at least eapi2, then, I am unsure if all packages currently shipped in emul packages could bump their eapi due compat with old systems. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Pacho Ramos schrieb: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages you mean something like this one? https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass That was the original eclass allowing cross-compile support, but required ebuilds to inherit it. multilib-portage is based on this, but does not require to modify the ebuilds themselves. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 13:30:41 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 13:03:56 +0200 Pacho Ramos pa...@gentoo.org wrote: That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) You could fix those ebuilds to inherit it too ;). autotools-utils was especially designed to use out-of-source builds for multilib in the future. I'm afraid the 'upper level' is technically impossible without either going into PM itself (which means waiting for EAPI 6 at least and getting some scary logic into it) or reinventing the phases alike ruby-ng/python-distutils-ng. Well, the latter may be useful to some degree; still, it would require each ebuild to redefine all phases. Then, I think that main blocker to use autotools-utils.eclass more widely is that it needs at least eapi2, then, I am unsure if all packages currently shipped in emul packages could bump their eapi due compat with old systems. I doubt that is an important problem anymore, considering that portage requires at least EAPI 2 (and some ebuilds use EAPI 3 already). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Clarify the as-is license?
On Sun, 23 Sep 2012, Rich Freeman wrote: Well, I can see legal problems any time you take a thousand things that all have a bunch of non-identical, informal licenses and treat them as the same. However, I don't think it is practical to do otherwise. I agree. Creating hundreds of license files because of minor variations in wording isn't useful. How about having an as-is-free and an as-is-nonfree. The easier thing on maintainers is to make one of those just as-is, and if we want to make sure we check them all the better thing is to not do that. However, making a new as-is-free and treating anything as-is as not free is probably good enough. I don't think it is wise to do the reverse, even though that involves the least amount of work. If we really decide to move things to a new license file, then I'd rather avoid the name as-is because it is partly the reason for the confusion. We should follow the OSI and SPDX [1] naming, unless there are good reasons against it. Concerning as-is-nonfree, we already have the slightly more specific freedist and free-noncomm. Ulrich [1] http://www.spdx.org/licenses/HPND
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 12:40 PM, Michał Górny wrote: On Sun, 23 Sep 2012 12:02:01 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. How is it stronger? By doing implicit magic on every ebuild? a) does not involve modifying ebuilds b) works in a larger scale c) is tested and developed for quite some time -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQXvsmAAoJEFpvPKfnPDWzZAcH/11b4Wng7f+nyDpbFQhanpLW 56mQy4IGmEvmEqgrYyBPLtnXWh+BtNu+j0ogS8hNMxsVXvDw6HvJGbeXwebcQ6VY OQS5l0IZvK9Zz+H4wm+ACv1i6fWPG9nRuMg8phRwfnq0jMIIF2lP1nll5T/2QYU/ fvPxiweKca9id4hozc0C0319vpVjEoX9a8/dBh6JXGNlzPq54bf7+6qep8O7mWGo 9bKXkoobwd22wUnBajcOFg4mbMu7cnKsTn0PhQBXo2+tEV5MhgugGe8USq99u8xA CQVVRcdbjyQZW90W8c0/Dniq8LMcTY6xoKmH5a2vG0dpHahYtKtCZ2sTruxgppc= =KNcl -END PGP SIGNATURE-
Re: [gentoo-dev] Clarify the as-is license?
On 09/23/2012 02:04 PM, Ulrich Mueller wrote: If we really decide to move things to a new license file, then I'd rather avoid the name as-is because it is partly the reason for the confusion. I agree on that. I saw it more than once that people use as-is for the license, just because there is an as is clause.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió: Pacho Ramos schrieb: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages you mean something like this one? https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass That was the original eclass allowing cross-compile support, but required ebuilds to inherit it. multilib-portage is based on this, but does not require to modify the ebuilds themselves. Yes, that is what I meant... but I don't find hard to modify ebuilds to inherit it :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 14:05:58 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 12:40 PM, Michał Górny wrote: On Sun, 23 Sep 2012 12:02:01 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. How is it stronger? By doing implicit magic on every ebuild? a) does not involve modifying ebuilds How can you tell whether a particular ebuild does install libraries which are suitable for multilib? Or are we enforcing multilib for every single program now? c) is tested and developed for quite some time Building packages on two ABIs was developed quite a long time ago, and was tested since. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El sáb, 22-09-2012 a las 23:24 +0200, Michał Górny escribió: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Use case: xorg packages, ask Matt. --- gx86/eclass/autotools-multilib.eclass | 72 +++ 1 file changed, 72 insertions(+) create mode 100644 gx86/eclass/autotools-multilib.eclass diff --git a/gx86/eclass/autotools-multilib.eclass b/gx86/eclass/autotools-multilib.eclass new file mode 100644 index 000..1a345a1 --- /dev/null +++ b/gx86/eclass/autotools-multilib.eclass @@ -0,0 +1,72 @@ +# Copyright 1999-2012 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 +# $Header: $ + +# @ECLASS: autotools-multilib.eclass +# @MAINTAINER: +# Michał Górny mgo...@gentoo.org +# @BLURB: autotools-utils wrapper for multilib builds +# @DESCRIPTION: +# The autotools-multilib.eclass is an autotools-utils.eclass(5) wrapper +# introducing support for building for more than one ABI (multilib). +# +# Inheriting this eclass sets IUSE=multilib and exports autotools-utils +# phase function wrappers which build the package for each supported ABI +# if the flag is enabled. Otherwise, it works like regular +# autotools-utils. [...] One problem that I remembered now: If every ebuild inheritting this eclass (either this one or similar) will add a multilib USE, people running multilib profiles will get it enabled for ALL packages inheritting it, causing them to see how their systems grow a lot because they will have 32bits libs for all packages, even when not needed. For example, in my systems I need gtk+ 32 bits libs, but not qt ones as I don't have any qt based app requiring 32bits installed. Maybe the way to workaround this would be to rename it to something like 32bits, that way if, for example, acroread RDEPENDs on gtk+[32bits], it would only be enabled for needed packages not all signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Michał, Pacho, and everyone else who suck epically at this: CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS! Thank you //Peter pgpJmV3IkjFsp.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Pacho Ramos schrieb: El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió: Pacho Ramos schrieb: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages you mean something like this one? https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass That was the original eclass allowing cross-compile support, but required ebuilds to inherit it. multilib-portage is based on this, but does not require to modify the ebuilds themselves. Yes, that is what I meant... but I don't find hard to modify ebuilds to inherit it :/ It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? The good solutions should not be made ugly to support corner cases. You are tying support to one specific build system, and one specific usage within ebuilds. That is what I would call a corner case :) Ebuilds already define a standardized way of building packages, why not use this directly ? I'm not saying your proposal is useless, it is indeed more efficient than a generic one, but rather that a generic solution is neither much more complicated nor that inefficient in comparison. -- this really starts to resemble multilib portage :) I've said already that multilib is a thing which could be done by eclasses and doesn't need making PM scary. And Tommy says that multilib-portage handles packages having IUSE=multilib fine. I agree with that, it also has two main advantages over multilib portage: it can be used right now and ensures that packages have their multilib builds tested before exposing it to users. A.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On 22/09/2012 20:42, Matt Turner wrote: I think this means make 32-bit binary packages' dependencies on amd64 not use the emul- packages? If so, that'd certainly be a component of getting rid of emul-linux-x86-xlibs. It's not in the scope of my project to get rid of /all/ of the emul- packages, but I agree that that is a worthwhile goal. Mostly I don't want to have to build Xaw in both variants given I use neither.. but that would happen if you just made the emul depend on the packages that are converted... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. The good solutions should not be made ugly to support corner cases. You are tying support to one specific build system, and one specific usage within ebuilds. That is what I would call a corner case :) Ebuilds already define a standardized way of building packages, why not use this directly ? I'm not saying your proposal is useless, it is indeed more efficient than a generic one, but rather that a generic solution is neither much more complicated nor that inefficient in comparison. It's a common case. A generic solution is more complicated if it is supposed to use phase functions exported by some eclass. By using a generic solution you lose the ability to 'automagically' use last exported function. Some time ago I suggested replacing 'default' with something like 'next' (which would allow one exported phase function to call the one from next inherited eclass) but I don't think I got any response. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 16:26:55 +0200 Peter Stuge pe...@stuge.se wrote: Michał, Pacho, and everyone else who suck epically at this: CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS! I've trimmed them in the next e-mail to the one you replied to :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 9:07 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 22/09/2012 20:42, Matt Turner wrote: I think this means make 32-bit binary packages' dependencies on amd64 not use the emul- packages? If so, that'd certainly be a component of getting rid of emul-linux-x86-xlibs. It's not in the scope of my project to get rid of /all/ of the emul- packages, but I agree that that is a worthwhile goal. Mostly I don't want to have to build Xaw in both variants given I use neither.. but that would happen if you just made the emul depend on the packages that are converted... Ahh, indeed. You mean that existing dependencies on emul-linux-x86-xlibs should be converted into finer-grained dependencies on individual libraries. Of course, that is a very good idea. In the case of Xaw, I added a deprecated USE flag recently that controls the building of the old Xaw6, so we're already working toward trimming Xaw from users' systems. :)
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 3:02 AM, hasufell hasuf...@gentoo.org wrote: I prefer the stronger solution. This is just a quick workaround. And I'd prefer if people who aren't involved with what I'm working on don't try to block my progress. I appreciate your opinion, and truthfully I'd just rather have portage handle this for me but until that time comes I'm going to use Michal's eclass.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 2:07 AM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. I'd much rather have portage handle this for me as well. Unfortunately, the last mail I see about multilib-portage is from two months ago. If it were in EAPI 5, I'd be happy to wait for it. If it even looked like it were progressing, I might wait. But, as you know, gentoo-dev is where ideas go to die. As far as ebuild conversions go, this is really simple. So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. That seems like a reasonable request. Let me re-read the previously mentioned thread and get back to you.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 5:30 AM, Pacho Ramos pa...@gentoo.org wrote: One problem that I remembered now: If every ebuild inheritting this eclass (either this one or similar) will add a multilib USE, people running multilib profiles will get it enabled for ALL packages inheritting it, causing them to see how their systems grow a lot because they will have 32bits libs for all packages, even when not needed. For example, in my systems I need gtk+ 32 bits libs, but not qt ones as I don't have any qt based app requiring 32bits installed. Currently, yes, that is the case. The fix is pretty simple though, and is in progress: https://bugs.gentoo.org/show_bug.cgi?id=435094 (previously mentioned in this thread...)
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On 09/23/2012 03:02 AM, hasufell wrote: On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. -1 I'm in favor of adding multilib functions to the package manager in a future EAPI, but I'm not convinced that the current multilib-portage branch is using the best design. For example, it recently came to my attention that it calls pkg_preinst in a loop for each multilib-ABI. This seems like a bad idea to me, since pkg_preinst often contains stuff that only needs to run once, rather than for each multilib-ABI. I would prefer that such loops be coded explicitly in pkg_preinst whenever they are needed, and approach taken by the proposed autotools-multilib.eclass is more in alignment with this preference. -- Thanks, Zac
Re: [gentoo-dev] Clarify the as-is license?
On Sun, 23 Sep 2012, hasufell wrote: If we really decide to move things to a new license file, then I'd rather avoid the name as-is because it is partly the reason for the confusion. I agree on that. I saw it more than once that people use as-is for the license, just because there is an as is clause. Right. Here's a small (but prominent) sample, namely all as-is packages from the amd64 livecd and stage3: - net-misc/ntp: as-is looks fine as main license, although some parts of the code are under different licenses like GPL (but I haven't checked in detail what gets installed). - sys-apps/hdparm: as-is approximates it (but different wording). Debian lists this package as BSD. - dev-util/yacc: public-domain according to README. - media-libs/libpng: Comes with its own license. Free. - media-libs/portaudio: MIT - net-misc/openssh: BSD-ish, something like BSD BSD-2 as-is BEER-WARE public-domain would be close. - net-wireless/rfkill: ISC - sys-apps/man-pages: Patchwork of files with different free licenses. as-is GPL-2+ BSD MIT LDP-1 public-domain would cover most of it. While the above are at least free software (mostly BSD/MIT like), I think that as-is is completely wrong for the following: - app-admin/passook: Seems to have no license at all. - net-wireless/zd1201-firmware: No license in tarball or on homepage. - net-wireless/prism54-firmware: Ditto, and package is mirror restricted. (How can it be on our install media then?) Ulrich
[gentoo-dev] [RFC] Multiple ABI support through package appending/partial removal
Hello, Since my previous idea of DYNAMIC_SLOTS proved too complex to design and implement, I would like to offer an another idea, based partially on what Ciaran mentioned. Before I start getting into details, I'd like to know your opinions, and what possible problems am I missing. To keep it clean, I will focus on Python ABIs but other languages and multilib could be handled in a similar manner. The problem === Right now, building packages for multiple Python ABIs is done using USE_EXPAND-based useflags. This is a working solution but it requires rebuilding the package for all ABIs whenever the chosen ABI list changes. While it may be not that important for most of the Python packages, it becomes such when it comes to things like boost or -- if we'd extend that to multilib -- say, llvm. In that case, whenever a newly-installed package requests a specific ABI, user has to spend twice as much time to rebuild the same version. The general idea While not getting too deep into ebuild syntax, the core part of the idea is to mark some of the USE_EXPAND variables 'special'. In this particular example, such a special flag group would be 'PYTHON_TARGETS'. Now, let's consider user installs a new package with one python_targets_python2_7 enabled. The package is built and installed like usual but aside to regular vdb files an additional file is introduced, listing all the installed files as 'belonging' to python_targets_python2_7. If user enables python_targets_python3_2 on the same package, the PM doesn't trigger a full rebuild. Instead, it builds the package with the new flag being the only flag in PYTHON_TARGETS. The new files are installed over the installed package (and added to CONTENTS in vdb), and the files in install image are listed in vdb as 'belonging' to python_targets_python3_2. Whenever files from two ABIs collide, package manager either replaces the installed files if the 'new' ABI is considered 'better' than the old one or preserves it. This follows the current behavior when multiple ABIs are built, and later builds overwrite files from earlier ones. At the point, the additional file contains something like (ugly pseudo-syntax): /usr/lib64/python2.7/foo.py python_targets_python2_7 /usr/lib64/python3.2/foo.py python_targets_python3_2 /usr/share/doc/foo-1.2.3/README.bz2 python_targets_python2_7 \ python_targets_python3_2 Now, if user requests disabling python_targets_python2_7 on the package, the package manager may not rebuild it as well. Instead, it removes python_targets_python2_7 from the above list, and unmerges the files which don't belong into any other ABI. Sadly, this will not 'downgrade' common files to another ABI but I believe that it is not really a killer-feature. Installing new packages and upgrading existing == Whenever a new package is to be built and multiple ABIs are requested, the package manager should split the build process between particular ABIs. Preferably, it should build all of them one-by-one, recording the 'belongs' entries from the image and then install them as a single package. Whenever a package is to be upgraded, all ABIs have to rebuilt. The package manager can handle it as a regular package upgrade, not considering 'belongs' entries more than in a fresh package install. Whenever a package is removed completely, the 'belongs' entries need not to be considered at all. Backwards compatibility === The solution aims to be fully compatible with package managers not supporting it. They should see it as a regular package with selected useflags, and an additional opaque vdb file. When such a package manager attempts to rebuild or upgrade such package, the vdb file should be removed, thus not introducing any ambiguity for PMs supporting it. The package removal is unaffected at all. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-09-23 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-09-23 23h59 UTC. Removals: Additions: media-fonts/oxygen-fonts2012-09-18 07:22:02 johu media-libs/glu 2012-09-18 23:24:45 chithanh games-fps/serious-sam-tse 2012-09-19 17:41:37 pinkbyte www-misc/profile-sync-daemon2012-09-19 18:52:56 hasufell sci-mathematics/gsl-shell 2012-09-20 16:09:24 grozin dev-python/pyfire 2012-09-21 08:20:23 pinkbyte games-fps/serious-sam-tfe 2012-09-22 01:59:43 pinkbyte sec-policy/selinux-flash2012-09-22 09:26:57 swift sec-policy/selinux-devicekit2012-09-22 09:26:59 swift sec-policy/selinux-vdagent 2012-09-22 09:27:09 swift sec-policy/selinux-chromium 2012-09-22 09:27:10 swift net-analyzer/nagios-check_rbl 2012-09-23 03:12:27 flameeyes media-sound/redoflacs 2012-09-23 04:06:03 yngwin net-misc/gvrpcd 2012-09-23 12:52:23 pinkbyte net-libs/libqmi 2012-09-23 21:28:19 vapier -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: Added Packages: media-fonts/oxygen-fonts,added,johu,2012-09-18 07:22:02 media-libs/glu,added,chithanh,2012-09-18 23:24:45 games-fps/serious-sam-tse,added,pinkbyte,2012-09-19 17:41:37 www-misc/profile-sync-daemon,added,hasufell,2012-09-19 18:52:56 sci-mathematics/gsl-shell,added,grozin,2012-09-20 16:09:24 dev-python/pyfire,added,pinkbyte,2012-09-21 08:20:23 games-fps/serious-sam-tfe,added,pinkbyte,2012-09-22 01:59:43 sec-policy/selinux-flash,added,swift,2012-09-22 09:26:57 sec-policy/selinux-devicekit,added,swift,2012-09-22 09:26:59 sec-policy/selinux-vdagent,added,swift,2012-09-22 09:27:09 sec-policy/selinux-chromium,added,swift,2012-09-22 09:27:10 net-analyzer/nagios-check_rbl,added,flameeyes,2012-09-23 03:12:27 media-sound/redoflacs,added,yngwin,2012-09-23 04:06:03 net-misc/gvrpcd,added,pinkbyte,2012-09-23 12:52:23 net-libs/libqmi,added,vapier,2012-09-23 21:28:19 Done.
Re: [gentoo-dev] Clarify the as-is license?
On Sun, Sep 23, 2012 at 5:37 PM, Ulrich Mueller u...@gentoo.org wrote: - net-misc/ntp: as-is looks fine as main license, although some parts of the code are under different licenses like GPL (but I haven't checked in detail what gets installed). Uh, if we're distributing the sources, and they contain GPL content, then the only valid answer is GPL, or nomirror. While the above are at least free software (mostly BSD/MIT like), I think that as-is is completely wrong for the following: - app-admin/passook: Seems to have no license at all. - net-wireless/zd1201-firmware: No license in tarball or on homepage. - net-wireless/prism54-firmware: Ditto, and package is mirror restricted. (How can it be on our install media then?) No license, no distribution, unless there is a declaration that it is in the public domain, in which case that is the license. Thanks for checking! Rich
Re: [gentoo-dev] Clarify the as-is license?
On Sun, 2012-09-23 at 23:37 +0200, Ulrich Mueller wrote: - net-wireless/zd1201-firmware: No license in tarball or on homepage. Ubuntu distributes it in their linux-firmware package with the following LICENCE.zd1201 file: The firmware was originally distributed by Zydas in their original driver package. (You can still find it at http://linux-lc100020.sourceforge.net/ ) This package was distributed under both the GPL and MPL. The firmware was in it in the form of a large array in a header file. More precisely, if you download the old Zydas driver source from http://sourceforge.net/projects/linux-lc100020/files/%28OLD%29%20wlan-ng%20based%20driver/ the license terms are The contents of this file are subject to the Mozilla Public License Version 1.1 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.mozilla.org/MPL/ Software distributed under the License is distributed on an AS IS basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. Alternatively, the contents of this file may be used under the terms of the GNU Public License version 2 (the GPL), in which case the provisions of the GPL are applicable instead of the above. If you wish to allow the use of your version of this file only under the terms of the GPL and not to allow others to use your version of this file under the MPL, indicate your decision by deleting the provisions above and replace them with the notice and other provisions required by the GPL. If you do not delete the provisions above, a recipient may use your version of this file under either the MPL or the GPL. tl;dr: LICENSE=|| ( MPL-1.1 GPL-2 ) -Alexandre.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On 23 September 2012 18:40, Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? No, it uses qmake, its own make tool. See qt4-build and qt4-r2 eclasses. KDE and a number of other reverse dependencies of the Qt libs do use cmake. I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. -- Best regards, Michał Górny -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-portage-dev] Try to specify how to get that a USE flag is present in current ebuild
On Sat, Sep 22, 2012 at 7:22 PM, Pacho Ramos pa...@gentoo.org wrote:
El sáb, 22-09-2012 a las 13:54 -0400, Mike Frysinger escribió:
On Friday 21 September 2012 15:08:20 Pacho Ramos wrote:
In that one, we try to use the following:
has vala ${IUSE//+/} ! use vala return 0
inherit eutils
use_if_iuse vala
-mike
I am aware of that one also, but Ciaran also wants to forbid it for the
same reason :S
Well I assume Ciaran wants to forbid it because he is attempting to
write a PMS compliant PM; but in order to use these ebuilds properly
he has to emulate the unspecified behavior that the ebuilds rely on
upon. His claim is that the council is supposed to forbid this
behavior (presumably to make his job less horrible) but I don't see
them beating down your door to change it (and the behavior is not
new.)
-A
Re: [gentoo-portage-dev] Try to specify how to get that a USE flag is present in current ebuild
El dom, 23-09-2012 a las 05:52 +, Alec Warner escribió:
On Sat, Sep 22, 2012 at 7:22 PM, Pacho Ramos pa...@gentoo.org wrote:
El sáb, 22-09-2012 a las 13:54 -0400, Mike Frysinger escribió:
On Friday 21 September 2012 15:08:20 Pacho Ramos wrote:
In that one, we try to use the following:
has vala ${IUSE//+/} ! use vala return 0
inherit eutils
use_if_iuse vala
-mike
I am aware of that one also, but Ciaran also wants to forbid it for the
same reason :S
Well I assume Ciaran wants to forbid it because he is attempting to
write a PMS compliant PM; but in order to use these ebuilds properly
he has to emulate the unspecified behavior that the ebuilds rely on
upon. His claim is that the council is supposed to forbid this
behavior (presumably to make his job less horrible) but I don't see
them beating down your door to change it (and the behavior is not
new.)
-A
My point of view is that, as this is already supported in portage (and
probably in other PMs as, otherwise, they would have had a lot of
problems with, for example, a lot of packages inheritting important
eclasses like gnome2, cmake-utils or xorg-2) and also used in the tree
for years, the easiest solution is to simply specify current behavior
for existing eapis, needing to wait for a new one to change that
behavior.
As I pointed in http://www.gossamer-threads.com/lists/gentoo/dev/260662
other options would be:
- wait for next eapi to specify that, the problem is that, if that eapi
take a long time to be approved, we would need to move all
eclasses/ebuilds to the other non-automatic way to later revert
them back.
- include this specification in eapi5 as it's still not allowed in the
tree (maybe for this a council meeting should be soon enough I guess)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes
El mié, 12-09-2012 a las 22:05 +0200, Pacho Ramos escribió: El jue, 02-08-2012 a las 15:56 -0700, Zac Medico escribió: On 08/01/2012 03:19 AM, Pacho Ramos wrote: On every openrc update I get dispatch-conf wanting to revert all my changes in /etc/conf.d files, like KEYMAP, clock... Is there any way to prevent it from doing that? Thanks a lot for the info Maybe you want to add those config files to frozen-files in /etc/dispatch-conf.conf. The problem is that I don't really want to have that files frozen (as they could need important changes in future versions). What I expect if dispatch-conf to skip changes like changing an uncommented line with a commented line, This looks like could be done with: # Automerge files comprising only whitespace and/or comments # (yes or no) replace-wscomments=no , setting it to yes in dispatch-conf.conf or changing YES to NO... but it's probably difficult to detect :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes
On 09/23/2012 03:59 AM, Pacho Ramos wrote: This looks like could be done with: # Automerge files comprising only whitespace and/or comments # (yes or no) replace-wscomments=no , setting it to yes in dispatch-conf.conf It seems like that option is only likely to benefit people who have disabled the default config-protect-if-modified FEATURES setting, and I'm not sure that it's a good idea to hide trivial differences from these people by default. -- Thanks, Zac
[gentoo-portage-dev] Please review: manpage-cleanup and -hdepend
Hi! I created 2 branches, one for manpage cleanup [1], and the other for adding hdepend documentation [2] and would like you to review and possible merge them. manpage-hdepend branches from manpage-cleanup (only 2 commits are exclusive to the former), so it is probably best to start with -cleanup and then skip over the common commits in -hdepend. Note: It is quite cumbersome to review Reorder and cleanup of ebuild(5) on the -cleanup branch as a diff. I recommend to just read the DESCRIPTION of the manpage instead. The rest should be more or less unchanged. Thanks, Dennis p.S: Please CC me, as I am not on the list. [1] https://github.com/devurandom/portage/commits/feature/manpage-cleanup [2] https://github.com/devurandom/portage/commits/feature/manpage-hdepend signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH 1/5] Adjust code of first paragraph of ebuild(5) to 80 char width
--- man/ebuild.5 | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index f4a53be..6fca6d4 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -4,12 +4,12 @@ ebuild \- the internal format, variables, and functions in an ebuild script .SH DESCRIPTION -The \fBebuild\fR(1) program accepts a single ebuild script as an argument. This script -contains variables and commands that specify how to download, unpack, -patch, compile, install and merge a particular software package from -its original sources. In addition to all of this, the ebuild script -can also contain pre/post install/remove commands, as required. All -ebuild scripts are written in bash. +The \fBebuild\fR(1) program accepts a single ebuild script as an argument. +This script contains variables and commands that specify how to download, +unpack, patch, compile, install and merge a particular software package from +its original sources. In addition to all of this, the ebuild script can also +contain pre/post install/remove commands, as required. All ebuild scripts are +written in bash. .SS Dependencies A \fIdepend atom\fR is simply a dependency that is used by portage when calculating -- 1.7.12
[gentoo-portage-dev] Please review: manpage-cleanup
Hi! I created a branch for documenting hdepend ([1] and this thread) and would like you to review and possibly merge it. This branch is based off my manpage-cleanup branch, hence I recommend reading/merging that before this one. Thanks, Dennis [1] https://github.com/devurandom/portage/commits/feature/manpage-hdepend
[gentoo-portage-dev] [PATCH 2/2] Doocument behaviour of --root-deps for EAPI 6+ in emerge(1)
--- man/emerge.1 | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/man/emerge.1 b/man/emerge.1 index ea6409c..61d86b7 100644 --- a/man/emerge.1 +++ b/man/emerge.1 @@ -711,10 +711,11 @@ of packages for \fBROOT\fR. This option is only meaningful when used together with \fBROOT\fR and it should not be enabled under normal circumstances! -For currently supported \fBEAPI\fR values, the build-time dependencies are -specified in the \fBDEPEND\fR variable. -However, behavior may change for new \fBEAPI\fRs when related extensions are -added in the future. +Affects \fBEAPI 5\fR and earlier ebuilds only. +\fBEAPI 6\fR and later provide \fBHDEPEND\fR as a new means to adjust +installation into \fI/\fR and \fBROOT\fR. +If \fBEAPI 5\fR and earlier ebuilds are built in the same \fBemerge\fR run as +\fBEAPI 6\fR and later ebuilds, this option affects only the former. .TP .BR \-\-select [ y | n ] Add specified packages to the world set (inverse of -- 1.7.12
[gentoo-portage-dev] [PATCH 2/6] Adjust code of first paragraph of ebuild(5) to 80 char width
--- man/ebuild.5 | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index f4a53be..6fca6d4 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -4,12 +4,12 @@ ebuild \- the internal format, variables, and functions in an ebuild script .SH DESCRIPTION -The \fBebuild\fR(1) program accepts a single ebuild script as an argument. This script -contains variables and commands that specify how to download, unpack, -patch, compile, install and merge a particular software package from -its original sources. In addition to all of this, the ebuild script -can also contain pre/post install/remove commands, as required. All -ebuild scripts are written in bash. +The \fBebuild\fR(1) program accepts a single ebuild script as an argument. +This script contains variables and commands that specify how to download, +unpack, patch, compile, install and merge a particular software package from +its original sources. In addition to all of this, the ebuild script can also +contain pre/post install/remove commands, as required. All ebuild scripts are +written in bash. .SS Dependencies A \fIdepend atom\fR is simply a dependency that is used by portage when calculating -- 1.7.12
[gentoo-portage-dev] [PATCH 3/6] Fix referencens to Dependencies section of ebuild(5)
--- man/ebuild.5 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 6fca6d4..f3d364e 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -544,7 +544,7 @@ override them. .TP .B DEPEND This should contain a list of all packages that are required for the -program to compile as described in \fBDEPENDENCIES\fR. +program to compile as described in \fBDependencies\fR. .TP .B RDEPEND This should contain a list of all packages that are required for this @@ -552,13 +552,13 @@ program to run (aka runtime depend). If this is not set in \fBEAPI 3\fR or earlier, then it defaults to the value of \fBDEPEND\fR. In \fBEAPI 4\fR or later, \fBRDEPEND\fR will never be implicitly set. -You may use the same syntax to vary dependencies as seen above in \fBDEPENDENCIES\fR. +You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. .TP .B PDEPEND This should contain a list of all packages that should be merged after this one, but may be merged before if need be. -You may use the same syntax to vary dependencies as seen above in \fBDEPENDENCIES\fR. +You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. .TP .B REQUIRED_USE Beginning with \fBEAPI 4\fR, the \fBREQUIRED_USE\fR variable can be -- 1.7.12
[gentoo-portage-dev] [PATCH 5/6] Improve wording of *DEPEND variable description in ebuild(5) a bit
--- man/ebuild.5 | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 3f28fce..5bb1afa 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -543,27 +543,32 @@ repo\-level USE settings, since profile and user configuration settings override them. .TP .B DEPEND -This should contain a list of all packages that are required for the -program to compile as described in \fBDependencies\fR. +This should contain a list of all packages that are required for the program +to compile (aka \fIbuildtime\fR dependencies). These are usually libraries and +headers. + +You may use the syntax described above in the \fBDependencies\fR section. .TP .B RDEPEND This should contain a list of all packages that are required for this -program to run (aka runtime depend). If this is not set in \fBEAPI 3\fR -or earlier, then it defaults to the value of \fBDEPEND\fR. In -\fBEAPI 4\fR or later, \fBRDEPEND\fR will never be implicitly set. +program to run (aka \fIruntime\fR dependencies). These are usually libraries. + +In \fBEAPI 3\fR or earlier, if this is not set, then it defaults to the value +of \fBDEPEND\fR. In \fBEAPI 4\fR or later, \fBRDEPEND\fR will never be +implicitly set. -You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. +You may use the syntax described above in the \fBDependencies\fR section. .TP .B PDEPEND This should contain a list of all packages that should be merged after this -one, but which may be installed by the package manager at any time, if that is -not possible. +one (aka \fIpost\fR merge dependencies), but which may be installed by the +package manager at any time, if that is not possible. .B ***WARNING*** .br Use this only as last resort to break cyclic dependencies! -You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. +You may use the syntax described above in the \fBDependencies\fR section. .TP .B REQUIRED_USE Beginning with \fBEAPI 4\fR, the \fBREQUIRED_USE\fR variable can be -- 1.7.12
[gentoo-portage-dev] [PATCH 6/6] Reorder description of --root-deps in emerge(1)
80 char width and max 1 sentence per line. --- man/emerge.1 | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/man/emerge.1 b/man/emerge.1 index da2c631..ea6409c 100644 --- a/man/emerge.1 +++ b/man/emerge.1 @@ -705,14 +705,16 @@ Set the \fBROOT\fR environment variable. .TP .BR \-\-root\-deps[=rdeps] If no argument is given then build\-time dependencies of packages for -\fBROOT\fR are installed to -\fBROOT\fR instead of /. If the \fBrdeps\fR argument is given then discard -all build\-time dependencies of packages for \fBROOT\fR. This option is -only meaningful when used together with \fBROOT\fR and it should not -be enabled under normal circumstances. For currently supported -\fBEAPI\fR values, the build-time dependencies are specified in the -\fBDEPEND\fR variable. However, behavior may change for new -\fBEAPI\fRs when related extensions are added in the future. +\fBROOT\fR are installed to \fBROOT\fR instead of /. +If the \fBrdeps\fR argument is given then discard all build\-time dependencies +of packages for \fBROOT\fR. +This option is only meaningful when used together with \fBROOT\fR and it should +not be enabled under normal circumstances! + +For currently supported \fBEAPI\fR values, the build-time dependencies are +specified in the \fBDEPEND\fR variable. +However, behavior may change for new \fBEAPI\fRs when related extensions are +added in the future. .TP .BR \-\-select [ y | n ] Add specified packages to the world set (inverse of -- 1.7.12
Re: [gentoo-portage-dev] Please review: manpage-cleanup
Subject should actually read: manpage-hdepend — I'm just not used to writing emails on the console using a text-editor alone… --Dennis signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH] use `readlink -f` if it works
Rather than always re-implementing `readlink -f` in shell, probe the host
tool first to see if it works.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
bin/misc-functions.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index ac08bd9..c8b7cc8 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -43,7 +43,20 @@ install_symlink_html_docs() {
}
# replacement for readlink -f or realpath
+READLINK_F_WORKS=
canonicalize() {
+ if [[ -z ${READLINK_F_WORKS} ]] ; then
+ if [[ $(readlink -f -- /../ 2/dev/null) == / ]] ; then
+ READLINK_F_WORKS=true
+ else
+ READLINK_F_WORKS=false
+ fi
+ fi
+ if ${READLINK_F_WORKS} ; then
+ readlink -f -- $@
+ return
+ fi
+
local f=$1 b n=10 wd=$(pwd)
while (( n-- 0 )); do
while [[ ${f: -1} = / ${#f} -gt 1 ]]; do
--
1.7.12
[gentoo-portage-dev] [PATCH] drop support for QA_DT_HASH/QA_STRICT_DT_HASH
These variables have been deprecated in favor of the new variables
QA_STRICT_FLAGS_IGNORED/QA_FLAGS_IGNORED, and the tree has been
converted over to the new ones, so drop the old vars.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
bin/misc-functions.sh | 25 -
1 file changed, 25 deletions(-)
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index c8b7cc8..55d37f2 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -167,8 +167,6 @@ install_qa_check() {
cd ${ED} || die cd failed
- # Merge QA_FLAGS_IGNORED and QA_DT_HASH into a single array, since
- # QA_DT_HASH is deprecated.
qa_var=QA_FLAGS_IGNORED_${ARCH/-/_}
eval [[ -n \${!qa_var} ]] QA_FLAGS_IGNORED=(\\${${qa_var}[@]}\)
if [[ ${#QA_FLAGS_IGNORED[@]} -eq 1 ]] ; then
@@ -179,29 +177,6 @@ install_qa_check() {
set -${shopts}
fi
- qa_var=QA_DT_HASH_${ARCH/-/_}
- eval [[ -n \${!qa_var} ]] QA_DT_HASH=(\\${${qa_var}[@]}\)
- if [[ ${#QA_DT_HASH[@]} -eq 1 ]] ; then
- local shopts=$-
- set -o noglob
- QA_DT_HASH=(${QA_DT_HASH})
- set +o noglob
- set -${shopts}
- fi
-
- if [[ -n ${QA_DT_HASH} ]] ; then
- QA_FLAGS_IGNORED=(${QA_FLAGS_IGNORED[@]} ${QA_DT_HASH[@]})
- unset QA_DT_HASH
- fi
-
- # Merge QA_STRICT_FLAGS_IGNORED and QA_STRICT_DT_HASH, since
- # QA_STRICT_DT_HASH is deprecated
- if [ ${QA_STRICT_FLAGS_IGNORED-unset} = unset ] \
- [ ${QA_STRICT_DT_HASH-unset} != unset ] ; then
- QA_STRICT_FLAGS_IGNORED=1
- unset QA_STRICT_DT_HASH
- fi
-
# Check for files built without respecting *FLAGS. Note that
# -frecord-gcc-switches must be in all *FLAGS variables, in
# order to avoid false positive results here.
--
1.7.12
Re: [gentoo-portage-dev] [PATCH] use `readlink -f` if it works
On 09/23/2012 05:28 PM, Mike Frysinger wrote: Rather than always re-implementing `readlink -f` in shell, probe the host tool first to see if it works. Looks good to me. -- Thanks, Zac
[gentoo-portage-dev] [PATCH] Implement host dependencies and targetroot USE flag
This patch implements host dependencies (HDEPEND) and dependencies only in
affect when ROOT != / (targetroot USE flag).
See: https://bugs.gentoo.org/show_bug.cgi?id=317337
See: http://thread.gmane.org/gmane.linux.gentoo.devel/80315
This fuctionality is only enabled for EAPI=5-hdepend and should not affect
other EAPIs. Changes:
1. HDEPEND dependencies. These are build-time dependencies which have to be
installed on the build machine (host, ROOT=/).
2. DEPEND dependencies now always refer to packages in ROOT (target);
destination of DEPEND is no longer determined by --root-deps.
3. targetroot USE flag. This is a special USE flag which is automatically
enabled when the ROOT for a package is different than /. The primary use case
for this is to make a package depend on itself in order to cross-compile. The
dependency needs to be conditional otherwise the package may not be installable
for ROOT=/.
The flag still needs to be added to IUSE to work. Example:
EAPI=5-hdepend
IUSE=... targetroot ...
HDEPEND=
targetroot? ( ~${CATEGORY}/${P} )
Also, the flag is implemented such that it is not considered by --newuse, which
makes sure that emerge from within the target system will not attempt to
rebuild every cross-compiled package.
I've tested this patch with packages in my cross-compile overlay which contains
some packages using the new support:
http://code.google.com/p/ambro-cross-overlay/
bin/ebuild.sh| 30 +++-
pym/_emerge/depgraph.py | 55 +---
pym/_emerge/main.py | 1 -
pym/portage/__init__.py | 4 +--
pym/portage/dbapi/bintree.py | 6 ++--
pym/portage/dbapi/porttree.py| 2 +-
pym/portage/dbapi/vartree.py | 1 +
pym/portage/eapi.py | 3 +-
pym/portage/package/ebuild/config.py | 11 +++-
9 files changed, 76 insertions(+), 37 deletions(-)
[gentoo-portage-dev] [PATCH] Implement host dependencies and targetroot USE flag
---
bin/ebuild.sh| 30 +++-
pym/_emerge/depgraph.py | 55 +---
pym/_emerge/main.py | 1 -
pym/portage/__init__.py | 4 +--
pym/portage/dbapi/bintree.py | 6 ++--
pym/portage/dbapi/porttree.py| 2 +-
pym/portage/dbapi/vartree.py | 1 +
pym/portage/eapi.py | 3 +-
pym/portage/package/ebuild/config.py | 11 +++-
9 files changed, 76 insertions(+), 37 deletions(-)
diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 79da2b5..a376d2f 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -215,6 +215,7 @@ inherit() {
local B_DEPEND
local B_RDEPEND
local B_PDEPEND
+ local B_HDEPEND
while [ $1 ]; do
location=${ECLASSDIR}/${1}.eclass
olocation=
@@ -257,20 +258,21 @@ inherit() {
EBUILD_OVERLAY_ECLASSES=${EBUILD_OVERLAY_ECLASSES} ${location}
fi
- #We need to back up the value of DEPEND and RDEPEND to B_DEPEND
and B_RDEPEND
+ #We need to back up the values of *DEPEND to B_*DEPEND
#(if set).. and then restore them after the inherit call.
#turn off glob expansion
set -f
# Retain the old data and restore it later.
- unset B_IUSE B_REQUIRED_USE B_DEPEND B_RDEPEND B_PDEPEND
+ unset B_IUSE B_REQUIRED_USE B_DEPEND B_RDEPEND B_PDEPEND
B_HDEPEND
[ ${IUSE+set} = set ] B_IUSE=${IUSE}
[ ${REQUIRED_USE+set} = set ]
B_REQUIRED_USE=${REQUIRED_USE}
[ ${DEPEND+set} = set ] B_DEPEND=${DEPEND}
[ ${RDEPEND+set}= set ] B_RDEPEND=${RDEPEND}
[ ${PDEPEND+set}= set ] B_PDEPEND=${PDEPEND}
- unset IUSE REQUIRED_USE DEPEND RDEPEND PDEPEND
+ [ ${HDEPEND+set}= set ] B_HDEPEND=${HDEPEND}
+ unset IUSE REQUIRED_USE DEPEND RDEPEND PDEPEND HDEPEND
#turn on glob expansion
set +f
@@ -286,6 +288,7 @@ inherit() {
[ ${DEPEND+set} = set ] E_DEPEND+=${E_DEPEND:+
}${DEPEND}
[ ${RDEPEND+set} = set ] E_RDEPEND+=${E_RDEPEND:+
}${RDEPEND}
[ ${PDEPEND+set} = set ] E_PDEPEND+=${E_PDEPEND:+
}${PDEPEND}
+ [ ${HDEPEND+set} = set ] E_HDEPEND+=${E_HDEPEND:+
}${HDEPEND}
[ ${B_IUSE+set} = set ] IUSE=${B_IUSE}
[ ${B_IUSE+set} = set ] || unset IUSE
@@ -302,6 +305,9 @@ inherit() {
[ ${B_PDEPEND+set} = set ] PDEPEND=${B_PDEPEND}
[ ${B_PDEPEND+set} = set ] || unset PDEPEND
+ [ ${B_HDEPEND+set} = set ] HDEPEND=${B_HDEPEND}
+ [ ${B_HDEPEND+set} = set ] || unset HDEPEND
+
#turn on glob expansion
set +f
@@ -528,8 +534,9 @@ if ! has $EBUILD_PHASE clean cleanrm ; then
# In order to ensure correct interaction between ebuilds and
# eclasses, they need to be unset before this process of
# interaction begins.
- unset EAPI DEPEND RDEPEND PDEPEND INHERITED IUSE REQUIRED_USE \
- ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND
E_PDEPEND
+ unset EAPI DEPEND RDEPEND PDEPEND HDEPEND INHERITED IUSE
REQUIRED_USE \
+ ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND
E_PDEPEND \
+ E_HDEPEND
if [[ $PORTAGE_DEBUG != 1 || ${-/x/} != $- ]] ; then
source $EBUILD || die error sourcing ebuild
@@ -560,9 +567,10 @@ if ! has $EBUILD_PHASE clean cleanrm ; then
DEPEND+=${DEPEND:+ }${E_DEPEND}
RDEPEND+=${RDEPEND:+ }${E_RDEPEND}
PDEPEND+=${PDEPEND:+ }${E_PDEPEND}
+ HDEPEND+=${HDEPEND:+ }${E_HDEPEND}
REQUIRED_USE+=${REQUIRED_USE:+ }${E_REQUIRED_USE}
- unset ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND E_PDEPEND
\
+ unset ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND E_PDEPEND
E_HDEPEND \
__INHERITED_QA_CACHE
# alphabetically ordered by $EBUILD_PHASE value
@@ -664,9 +672,17 @@ if [[ $EBUILD_PHASE = depend ]] ; then
auxdbkeys=DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE
DESCRIPTION KEYWORDS INHERITED IUSE REQUIRED_USE PDEPEND
PROVIDE EAPI
- PROPERTIES DEFINED_PHASES UNUSED_05 UNUSED_04
+ PROPERTIES DEFINED_PHASES HDEPEND UNUSED_04
UNUSED_03 UNUSED_02 UNUSED_01
+ case $EAPI in
+ 5-hdepend)
+ ;;
+ *)
+ unset HDEPEND
+ ;;
+ esac
+
# The extra $(echo) commands
Re: [gentoo-portage-dev] [PATCH] drop support for QA_DT_HASH/QA_STRICT_DT_HASH
On 09/23/2012 05:49 PM, Mike Frysinger wrote: These variables have been deprecated in favor of the new variables QA_STRICT_FLAGS_IGNORED/QA_FLAGS_IGNORED, and the tree has been converted over to the new ones, so drop the old vars. You can also drop those variables from man/ebuild.5 and make.conf.5, but otherwise it looks good. -- Thanks, Zac
[gentoo-portage-dev] [PATCH] Implement host dependencies and targetroot USE flag
Update: added eapi_has_hdepend() and eapi_has_targetroot() to pym/portage/eapi.py to reduce the number of times 5-hdepend appears in the code. bin/ebuild.sh| 30 ++- pym/_emerge/depgraph.py | 57 +--- pym/_emerge/main.py | 1 - pym/portage/__init__.py | 4 +-- pym/portage/dbapi/bintree.py | 6 ++-- pym/portage/dbapi/porttree.py| 2 +- pym/portage/dbapi/vartree.py | 1 + pym/portage/eapi.py | 9 +- pym/portage/package/ebuild/config.py | 14 +++-- 9 files changed, 85 insertions(+), 39 deletions(-)
[gentoo-portage-dev] [PATCH] Implement host dependencies (HDEPEND) and dependencies only in affect when ROOT != / (targetroot flag).
---
bin/ebuild.sh| 30 ++-
pym/_emerge/depgraph.py | 57 +---
pym/_emerge/main.py | 1 -
pym/portage/__init__.py | 4 +--
pym/portage/dbapi/bintree.py | 6 ++--
pym/portage/dbapi/porttree.py| 2 +-
pym/portage/dbapi/vartree.py | 1 +
pym/portage/eapi.py | 9 +-
pym/portage/package/ebuild/config.py | 14 +++--
9 files changed, 85 insertions(+), 39 deletions(-)
diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 79da2b5..a376d2f 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -215,6 +215,7 @@ inherit() {
local B_DEPEND
local B_RDEPEND
local B_PDEPEND
+ local B_HDEPEND
while [ $1 ]; do
location=${ECLASSDIR}/${1}.eclass
olocation=
@@ -257,20 +258,21 @@ inherit() {
EBUILD_OVERLAY_ECLASSES=${EBUILD_OVERLAY_ECLASSES} ${location}
fi
- #We need to back up the value of DEPEND and RDEPEND to B_DEPEND
and B_RDEPEND
+ #We need to back up the values of *DEPEND to B_*DEPEND
#(if set).. and then restore them after the inherit call.
#turn off glob expansion
set -f
# Retain the old data and restore it later.
- unset B_IUSE B_REQUIRED_USE B_DEPEND B_RDEPEND B_PDEPEND
+ unset B_IUSE B_REQUIRED_USE B_DEPEND B_RDEPEND B_PDEPEND
B_HDEPEND
[ ${IUSE+set} = set ] B_IUSE=${IUSE}
[ ${REQUIRED_USE+set} = set ]
B_REQUIRED_USE=${REQUIRED_USE}
[ ${DEPEND+set} = set ] B_DEPEND=${DEPEND}
[ ${RDEPEND+set}= set ] B_RDEPEND=${RDEPEND}
[ ${PDEPEND+set}= set ] B_PDEPEND=${PDEPEND}
- unset IUSE REQUIRED_USE DEPEND RDEPEND PDEPEND
+ [ ${HDEPEND+set}= set ] B_HDEPEND=${HDEPEND}
+ unset IUSE REQUIRED_USE DEPEND RDEPEND PDEPEND HDEPEND
#turn on glob expansion
set +f
@@ -286,6 +288,7 @@ inherit() {
[ ${DEPEND+set} = set ] E_DEPEND+=${E_DEPEND:+
}${DEPEND}
[ ${RDEPEND+set} = set ] E_RDEPEND+=${E_RDEPEND:+
}${RDEPEND}
[ ${PDEPEND+set} = set ] E_PDEPEND+=${E_PDEPEND:+
}${PDEPEND}
+ [ ${HDEPEND+set} = set ] E_HDEPEND+=${E_HDEPEND:+
}${HDEPEND}
[ ${B_IUSE+set} = set ] IUSE=${B_IUSE}
[ ${B_IUSE+set} = set ] || unset IUSE
@@ -302,6 +305,9 @@ inherit() {
[ ${B_PDEPEND+set} = set ] PDEPEND=${B_PDEPEND}
[ ${B_PDEPEND+set} = set ] || unset PDEPEND
+ [ ${B_HDEPEND+set} = set ] HDEPEND=${B_HDEPEND}
+ [ ${B_HDEPEND+set} = set ] || unset HDEPEND
+
#turn on glob expansion
set +f
@@ -528,8 +534,9 @@ if ! has $EBUILD_PHASE clean cleanrm ; then
# In order to ensure correct interaction between ebuilds and
# eclasses, they need to be unset before this process of
# interaction begins.
- unset EAPI DEPEND RDEPEND PDEPEND INHERITED IUSE REQUIRED_USE \
- ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND
E_PDEPEND
+ unset EAPI DEPEND RDEPEND PDEPEND HDEPEND INHERITED IUSE
REQUIRED_USE \
+ ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND
E_PDEPEND \
+ E_HDEPEND
if [[ $PORTAGE_DEBUG != 1 || ${-/x/} != $- ]] ; then
source $EBUILD || die error sourcing ebuild
@@ -560,9 +567,10 @@ if ! has $EBUILD_PHASE clean cleanrm ; then
DEPEND+=${DEPEND:+ }${E_DEPEND}
RDEPEND+=${RDEPEND:+ }${E_RDEPEND}
PDEPEND+=${PDEPEND:+ }${E_PDEPEND}
+ HDEPEND+=${HDEPEND:+ }${E_HDEPEND}
REQUIRED_USE+=${REQUIRED_USE:+ }${E_REQUIRED_USE}
- unset ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND E_PDEPEND
\
+ unset ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND E_PDEPEND
E_HDEPEND \
__INHERITED_QA_CACHE
# alphabetically ordered by $EBUILD_PHASE value
@@ -664,9 +672,17 @@ if [[ $EBUILD_PHASE = depend ]] ; then
auxdbkeys=DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE
DESCRIPTION KEYWORDS INHERITED IUSE REQUIRED_USE PDEPEND
PROVIDE EAPI
- PROPERTIES DEFINED_PHASES UNUSED_05 UNUSED_04
+ PROPERTIES DEFINED_PHASES HDEPEND UNUSED_04
UNUSED_03 UNUSED_02 UNUSED_01
+ case $EAPI in
+ 5-hdepend)
+ ;;
+ *)
+ unset HDEPEND
+ ;;
+ esac
+
# The extra $(echo) commands
Re: [gentoo-portage-dev] Please review: manpage-cleanup
On 09/23/2012 03:25 PM, Dennis Schridde wrote: Hi! I created a branch for manpage cleanup ([1] and this thread) and would like you to review and possibly merge it. Note: It is quite cumbersome to review Reorder and cleanup of ebuild(5) as a diff. I recommend to just read the DESCRIPTION of the manpage instead. The rest should be more or less unchanged. Thanks, Dennis [1] https://github.com/devurandom/portage/commits/feature/manpage-cleanup Thanks, I've applied all 6 patches: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=af1a287b1dc771901f1b30f2166d20c1758e8587 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2e580d2852789b2c5deb922555f73643d0b9617a http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a1a8a79a76fd1be60f6fcf992efcbc1d98d0f941 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f2da08db6ad7b8c207a58f75e4daf96a74f29c56 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9dd83334c56262de44b0efa3c98777f1a3cc27af http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=62525844120c5308830c7140b9d5f037a4afe9c9 -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH] Implement host dependencies (HDEPEND) and dependencies only in affect when ROOT != / (targetroot flag).
On Sunday 23 September 2012 22:06:43 Ambroz Bizjak wrote:
+ case $EAPI in
case ${EAPI} in
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] drop support for QA_DT_HASH/QA_STRICT_DT_HASH
On Sunday 23 September 2012 21:39:45 Zac Medico wrote: On 09/23/2012 05:49 PM, Mike Frysinger wrote: These variables have been deprecated in favor of the new variables QA_STRICT_FLAGS_IGNORED/QA_FLAGS_IGNORED, and the tree has been converted over to the new ones, so drop the old vars. You can also drop those variables from man/ebuild.5 and make.conf.5, but otherwise it looks good. done pushed -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Implement host dependencies (HDEPEND) and dependencies only in affect when ROOT != / (targetroot flag).
On 09/23/2012 08:44 PM, Mike Frysinger wrote:
On Sunday 23 September 2012 22:06:43 Ambroz Bizjak wrote:
+case $EAPI in
case ${EAPI} in
-mike
If somebody manages to corrupt the EAPI with an invalid value containing
space, then you can get a bash syntax error there if ${EAPI} is
unquoted. Yeah, it's a user error, but it could confuse them even more
than they are already if they see the syntax error and think that
portage is at fault. Also, we might consider that a corrupt EAPI can
come from a binary package (or /var/db/pkg) enviroment.bz2, and so it
may not even be the current user who is at fault.
--
Thanks,
Zac
Re: [gentoo-portage-dev] [PATCH] Implement host dependencies (HDEPEND) and dependencies only in affect when ROOT != / (targetroot flag).
On 09/23/2012 09:39 PM, Mike Frysinger wrote:
On Sunday 23 September 2012 23:53:10 Zac Medico wrote:
On 09/23/2012 08:44 PM, Mike Frysinger wrote:
On Sunday 23 September 2012 22:06:43 Ambroz Bizjak wrote:
+ case $EAPI in
case ${EAPI} in
If somebody manages to corrupt the EAPI with an invalid value containing
space, then you can get a bash syntax error there if ${EAPI} is
unquoted. Yeah, it's a user error, but it could confuse them even more
than they are already if they see the syntax error and think that
portage is at fault. Also, we might consider that a corrupt EAPI can
come from a binary package (or /var/db/pkg) enviroment.bz2, and so it
may not even be the current user who is at fault.
i don't think that's true. case is sane unlike `test` and `[`.
$ f='a b c'; case ${f} in *) echo yeah;; esac
yeah
-mike
Sorry, my mistake. I could have sworn that I was able to trigger a
syntax error with this in the past.
--
Thanks,
Zac
