On 16:18 Tue 11 Dec , Matsuu Takuto (matsuu) wrote:
> 1.1 net-misc/scponly/scponly-4.6-r3.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/scponly/scponly-4.6-r3.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86
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
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
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 q
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
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 con
Thomas Anderson wrote:
On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote:
Doug Klima schrieb:
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 real
On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote:
> Doug Klima schrieb:
> > 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.
>
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
Doug Klima schrieb:
> 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 signature
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..
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
did we decide where EAPI goes in an ebuild?
yes, just above the inherit
that's the safest and simplest thing to do, anyway
zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
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 "
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 y
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
> >
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 reason
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 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
В Втр, 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}.
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
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
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
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 litt
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
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 constrai
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 con
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"
> > > ...
> > > } >>
"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
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
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 stri
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
>
31 matches
Mail list logo
