-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/28/2013 10:12 PM, hero...@gentoo.org wrote:
> "Rick \"Zero_Chaos\" Farina" writes:
>
>> On 09/28/2013 03:00 AM, Ulrich Mueller wrote:
On Sat, 28 Sep 2013, heroxbd wrote:
>>>
I am revisiting this topic based on previous discussion
"Rick \"Zero_Chaos\" Farina" writes:
> On 09/28/2013 03:00 AM, Ulrich Mueller wrote:
>>> On Sat, 28 Sep 2013, heroxbd wrote:
>>
>>> I am revisiting this topic based on previous discussions[1,2,3].
>>
>>> There seems to be a constant need for toolchain with a new EAPI. The
>>> only block is
Kent Fredric wrote:
>
>> this dependency will install for a user with unstable keywords
>>
>
> That, in itself, indicates the user is usually OK with "new versions of
> things" ;)
You are intentionally confusing "new version" (AKA upgrade) with
_additional_ installation of a package, just because
Kent Fredric wrote:
> --001a11336248343a2604e7770011
> Content-Type: text/plain; charset=UTF-8
>
> On 28 September 2013 23:36, Martin Vaeth
>wrote:
>
>>
>> Concerning the eclass idea which was already mentioned and
>> which is perhaps even better than my suggeestion from the
>> other posting, sinc
Kent Fredric wrote:
>>
> So are you basically suggesting that for dual life modules, we simply
> ignore that they're dual-lifeable, and then when upstream splits a package
> from core so that its no longer dual life, that we simply ignore that too,
> and fake it still being core for the forseeable
On 29 September 2013 09:14, Martin Vaeth
wrote:
> this dependency will install for a user with
> unstable keywords
>
That, in itself, indicates the user is usually OK with "new versions of
things" ;)
corelist -a says virtual/perl-Digest-MD5-2.520.0 should || ( perl v5.18 )
Though that virtual
On 29 September 2013 09:14, Martin Vaeth
wrote:
> the
> dependencies would not pull in unnecessary packages for the user.
>
Its just every time you say "unnessecary", that also implies that users **
NEVER** want new versions of dependencies.
That is just not true for most of the gentoo tree. If
Kent Fredric wrote:
>>
>> 1. The virtual does not even exist :)
>>
>
> Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0
In this case the virtual is buggy, becaues it does not contain
|| ( dev-lang/perl-5.18* ... )
Due to this, this particular example is not so ideal: I wanted t
On 29 September 2013 08:51, Ciaran McCreesh
wrote:
> The only reason anyone can make that claim is that no-one really knows
> what slot dictionaries are or how they'd work in practice. Until
> there's a rough description of how they work and a prototype
> implementation, "subslot dictionaries" is
On 28 September 2013 23:36, Martin Vaeth
wrote:
>
> Concerning the eclass idea which was already mentioned and
> which is perhaps even better than my suggeestion from the
> other posting, since it avoids some of the disadvantages:
>
> > by having an eclass that translates a special variable, say,
On Sun, 29 Sep 2013 08:47:52 +1300
Kent Fredric wrote:
> For that, a slot-dict approach is far more sane.
The only reason anyone can make that claim is that no-one really knows
what slot dictionaries are or how they'd work in practice. Until
there's a rough description of how they work and a prot
On 28 September 2013 22:46, Martin Vaeth
wrote:
> Kent Fredric wrote:
> >
> > you'll still need logic like "|| (
> > dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor
> )"
> > to just deal with the reality of what upstream are asking for.
>
> My point is that the perl ebuild
On 28 September 2013 22:31, Martin Vaeth
wrote:
>
> Note that it would be stupid to depend on e.g.
> =virtual/perl-Term-ANSIColor-4.02
> for several reason:
>
> 1. The virtual does not even exist :)
>
Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0 ,
because upstreams versionin
On 2013-09-28, at 9:43 AM, Davide Pesavento wrote:
> On Fri, Sep 27, 2013 at 4:44 PM, Michał Górny wrote:
>> Dnia 2013-09-26, o godz. 17:24:49
>> Davide Pesavento napisał(a):
>>
>>> On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric wrote:
On 26 September 2013 19:53, Michał Górny wrot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/28/2013 03:00 AM, Ulrich Mueller wrote:
>> On Sat, 28 Sep 2013, heroxbd wrote:
>
>> I am revisiting this topic based on previous discussions[1,2,3].
>
>> There seems to be a constant need for toolchain with a new EAPI. The
>> only block is
On Fri, Sep 27, 2013 at 4:44 PM, Michał Górny wrote:
> Dnia 2013-09-26, o godz. 17:24:49
> Davide Pesavento napisał(a):
>
>> On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric wrote:
>> >
>> > On 26 September 2013 19:53, Michał Górny wrote:
>> >>
>> >> How do we handle packages which install multipl
On Thu, Sep 26, 2013 at 7:39 PM, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 26/09/13 11:24 AM, Davide Pesavento wrote:
>> On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric
>> wrote:
>>>
>>> On 26 September 2013 19:53, Michał Górny
>>> wrote:
How do w
Kent Fredric wrote:
>
> I mean, the reason virtuals suck is predominantly the fact we have to
> update the conditionals to accurately reflect the version on the virtual
Concerning the eclass idea which was already mentioned and
which is perhaps even better than my suggeestion from the
other posti
Kent Fredric wrote:
>
> you'll still need logic like "|| (
> dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor )"
> to just deal with the reality of what upstream are asking for.
My point is that the perl ebuild need not necessarily follow upstream:
It follows what the perl
Matt Turner wrote:
>
>> || ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor )
>> and possibly change this if perl-5.20 does no longer contain
>> perl-Term-ANSIColor.
>
> Isn't that exactly what the virtual should do?
One can discuss what it *should* do, but it is certainly not
what happens, bec
> On Sat, 28 Sep 2013, heroxbd wrote:
> I am revisiting this topic based on previous discussions[1,2,3].
> There seems to be a constant need for toolchain with a new EAPI. The
> only block is "how can we upgrade from an ancient system?", "don't
> bump or the upgrade path will be break". Let'
21 matches
Mail list logo
