On Dec 11, 2007 6:03 AM, Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 10 December 2007, Donnie Berkholz wrote:
{
...
echo CONFIG_EAP_SAKE=y
...
} ${CONFIG}
cat -EOF ${CONFIG}
...
CONFIG_EAP_SAKE=y
...
EOF
-mike
Mike,
On Mon, 10 Dec 2007 11:42:38 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
You've made these assertions about confusion and breakage, and I
would like to understand the reasoning behind them. I don't
understand how it would be different than any other SLOT, because
they're already a string.
Hello.
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
...
done
The problem with this doesn't work if
Nirbheek Chauhan [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Tue, 11 Dec 2007 01:14:06 +0530:
On Dec 10, 2007 8:44 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
That would still mean everything relies on n ebuilds with mutual
blocks. Even if that would work and it block
On Tuesday 11 December 2007, Denis Dupeyron wrote:
On Dec 11, 2007 6:03 AM, Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 10 December 2007, Donnie Berkholz wrote:
{
...
echo CONFIG_EAP_SAKE=y
...
} ${CONFIG}
cat -EOF
On Dec 11, 2007 8:17 AM, Peter Volkov [EMAIL PROTECTED] wrote:
Hello.
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in
On 11:17 Tue 11 Dec , Peter Volkov wrote:
FONT_CONF=(path1 path2)
for conffile in [EMAIL PROTECTED]; do
...
done
But is this good idea? Are there better?
Roy solved a similar problem in baselayout-2 using hardcoded newlines,
although it had the additional constraint of sh
On Tuesday 11 December 2007 08:17:12 Peter Volkov wrote:
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
On Tuesday 11 December 2007 08:44:51 Donnie Berkholz wrote:
Roy solved a similar problem in baselayout-2 using hardcoded newlines,
although it had the additional constraint of sh compatibility. It's
worth considering code clarity between that and arrays.
Only because some commands could
On Dec 11, 2007 5:57 AM, Steve Long [EMAIL PROTECTED] wrote:
I don't find the argument for versioning the scm live ebuild compelling.
The point wrt comparison, ie foo-1-scm is 2.0.1, doesn't seem enough; it'd
be better to slot that imo, and have a slot identifier[1] in the existing
cvs digit
On Dec 11, 2007 1:51 PM, Duncan [EMAIL PROTECTED] wrote:
But what about when there's a dependency on any of several branches?
That gets hard to maintain if there are multiple ebuilds with similar
dependencies.
How does it become hard to maintain? Different branch ebuilds are
still the same
В Втр, 11/12/2007 в 10:38 +, Roy Marples пишет:
FONT_CONF=path1:path2
IFS=.
IIUC should be IFS=:
for for conffile in ${FONT_CONF}; do
done
unset IFS
That way you work the same way as the classic $PATH variable.
But this seems to fail if we have ':' inside path{1,2}. Is that
On Tue, 11 Dec 2007 16:36:51 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
The idea is that no one would want to automatically upgrade to a
branch (because you cannot define upgrade for branches), so make it
manual.
...and this is why branches shouldn't be treated like versions. They
have
On Dec 11, 2007 5:57 AM, Steve Long [EMAIL PROTECTED] wrote:
I don't find the argument for versioning the scm live ebuild compelling.
The point wrt comparison, ie foo-1-scm is 2.0.1, doesn't seem enough; it'd
be better to slot that imo, and have a slot identifier[1] in the existing
cvs digit
On Tuesday 11 December 2007 11:14:49 Peter Volkov wrote:
That way you work the same way as the classic $PATH variable.
But this seems to fail if we have ':' inside path{1,2}. Is that true?
For PATH the same question stands, but I think that ':' is used there
for historical reasons.
Yes,
On Dec 11, 2007 9:11 AM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
On Mon, 10 Dec 2007 11:42:38 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
You've made these assertions about confusion and breakage, and I
would like to understand the reasoning behind them.
[...]
For my reasoning... just
On Dec 11, 2007 4:47 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
On Tue, 11 Dec 2007 16:36:51 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
The idea is that no one would want to automatically upgrade to a
branch (because you cannot define upgrade for branches), so make it
manual.
Donnie Berkholz [EMAIL PROTECTED]:
While we're getting a bit off the original topic here, it occurred to
me that using SLOTs for this, in combination with various SLOT deps
and SLOT blockers, might work. Then one could use a search tool that
would display SLOTs to show you which branch you're
On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 15:49 Sat 08 Dec , Alon Bar-Lev wrote:
Hello,
I want to make gnupg-2 stable.
The problem is that gnupg-1.9 was slotted as slot 1.9 and made stable.
So now we have two slots, slot 0 and slot 1.9.
gnupg-2 is
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
Cardoe did we decide where EAPI goes in an ebuild?
zmedico yes, just above the inherit
zmedico that's the safest and simplest thing to do, anyway
Cardoe zmedico: what if I have EAPI=2 above the
On 22:49 Tue 11 Dec , Alon Bar-Lev wrote:
On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 15:49 Sat 08 Dec , Alon Bar-Lev wrote:
Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather
than SLOT 1.9?
he end result would be one slot... If I
Doug Klima schrieb:
Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
if an eclass sets EAPI, then the ebuild shouldn't... make it two
eclasses if needed or plain bump them if really really needed.
Greetz
Jokey
signature.asc
Description: OpenPGP digital
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima [EMAIL PROTECTED] wrote:
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
The only sane solution I can think of is that eclasses shouldn't be
allowed to change EAPI, but use conditionals to behave
On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote:
Doug Klima schrieb:
Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
if an eclass sets EAPI, then the ebuild shouldn't... make it two
eclasses if needed or plain bump them if really really needed.
Thomas Anderson wrote:
On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote:
Doug Klima schrieb:
Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
if an eclass sets EAPI, then the ebuild shouldn't... make it two
eclasses if needed or plain bump them if
Marius Mauch wrote:
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima [EMAIL PROTECTED] wrote:
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
The only sane solution I can think of is that eclasses shouldn't be
allowed to change EAPI, but use
Peter Volkov wrote:
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
...
done
The problem with
On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote:
gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting
should be used.
Drop in according to YOU, which I have taken issue with since 1/1/07.
Per last upstream release, and every one since 2.x was release, just as
I have
On 12/12/07, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 22:49 Tue 11 Dec , Alon Bar-Lev wrote:
On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 15:49 Sat 08 Dec , Alon Bar-Lev wrote:
Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather
On 12/12/07, William L. Thomson Jr. [EMAIL PROTECTED] wrote:
On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote:
gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting
should be used.
Drop in according to YOU, which I have taken issue with since 1/1/07.
Per last
30 matches
Mail list logo
