Re: [gentoo-portage-dev] support multiple eclass variants (aka unstable eclasses)
On 07/08/2014 07:11 PM, Sebastian Luther wrote: Am 08.07.2014 18:58, schrieb Michael Haubenwallner: Hello fellow Portage developers, attached portage patch draft aims to allow for easy distributing eclasses to be tested by multiple tinderboxes on various architectures, without being active for normal installs. What does the patch allow you to do, that you can't do right now? (i.e. put an eclass with the same name in an repository and use eclass-overrides to force its use in another repo?) Is there an easy way to use the eclasses from the overriding tree, but not the (usually newer) ebuilds from there - such as 'configure but disable repo (except for use in eclass-override)'? Thanks! /haubi/
Re: [gentoo-portage-dev] support multiple eclass variants (aka unstable eclasses)
Am 08.07.2014 18:58, schrieb Michael Haubenwallner: Hello fellow Portage developers, attached portage patch draft aims to allow for easy distributing eclasses to be tested by multiple tinderboxes on various architectures, without being active for normal installs. What does the patch allow you to do, that you can't do right now? (i.e. put an eclass with the same name in an repository and use eclass-overrides to force its use in another repo?) Usage is to have in make.conf (or profile): PORTAGE_ECLASS_VARIANTS=testing and for the eclass: to live in tree-or-overlay/eclass/testing/ Thoughts? (even for var-naming, manpage yes/no/wording, ...) There are lots of places to update (including python code). See git grep eclass. Thank you! /haubi/
Re: [gentoo-portage-dev] support multiple eclass variants (aka unstable eclasses)
Am 2014-07-08 19:11, schrieb Sebastian Luther: Am 08.07.2014 18:58, schrieb Michael Haubenwallner: Hello fellow Portage developers, attached portage patch draft aims to allow for easy distributing eclasses to be tested by multiple tinderboxes on various architectures, without being active for normal installs. What does the patch allow you to do, that you can't do right now? (i.e. put an eclass with the same name in an repository and use eclass-overrides to force its use in another repo?) Ohw, haven't been aware of that - will try first. Thanks! /haubi/