-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
Just so we're clear... if gentoo-x86 wants to define their own base
template all ebuilds in that repo use, that's fine. That's a
different beast from moving the format definition into the tree
though.
Kind of curious if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
Zac Medico wrote:
Incompatible changes for a given EAPI specification are simply unacceptable.
People really should know better than that. If not, educate them.
See this is a bad idea. If you give them a hand, they take the
Zac Medico wrote:
If we implement the repo-level profile, it can have a
bashrc (much like profile.bashrc) that acts as a repo-level ebuild template
(like install-helpers.eclass). Actually, the repo-level profile already
exists
in the form of files such as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Stelling wrote:
repo-level profile, we move parts of the EAPI out into the tree, which
is a bad idea because we are unable to support multiple versions. As the
EAPI needed for the ebuild is unknown when sourcing
install-helpers.eclass, we're
On Thu, Sep 07, 2006 at 09:32:04AM -0700, Zac Medico wrote:
Simon Stelling wrote:
repo-level profile, we move parts of the EAPI out into the tree, which
is a bad idea because we are unable to support multiple versions. As the
EAPI needed for the ebuild is unknown when sourcing
Zac Medico wrote:
Well, if the metadata generation step is viewed as being separate from the
rest,
and the helpers aren't needed during that step, then it's possible to get the
EAPI from the ebuild without the helpers being in the environment. Once the
EAPI is known, the package manager can
Brian Harring wrote:
Make this change, and it means that all overlays that can function as
standalone, must bundle the eapi helpers themselves.
Not true. I don't have to add eutils.eclass to my overlay to use epatch.
Same goes for install-helpers.eclass. Standalone-repos will have that
On Thu, Sep 07, 2006 at 07:11:01PM +0200, Simon Stelling wrote:
Brian Harring wrote:
Make this change, and it means that all overlays that can function as
standalone, must bundle the eapi helpers themselves.
Standalone-repos will have that
problem, but there is none yet to my knowledge.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Stelling wrote:
Brian Harring wrote:
B) fragmentation this implicitly enables
isn't good.
I agree here.
Fragmentation is always a potential with free and open software. People can
fork if they want or collaborate if they want. The
On Thu, Sep 07, 2006 at 10:22:38AM -0700, Zac Medico wrote:
Simon Stelling wrote:
Zac Medico wrote:
Well, if the metadata generation step is viewed as being separate from the
rest,
and the helpers aren't needed during that step, then it's possible to get
the
EAPI from the ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Stelling wrote:
Zac Medico wrote:
Well, if the metadata generation step is viewed as being separate from the
rest,
and the helpers aren't needed during that step, then it's possible to get the
EAPI from the ebuild without the helpers being
Hi all,
I have thought a bit more about how to better organize the bash-side of
portage and came to the conclusion that modularization of ebuild.sh (as
proposed in the recent thread Refactoring ebuild.sh) can't be the only
and is not the best thing to do.
There is a fair amount of shell scripts
12 matches
Mail list logo
