This is particularly useful for people who run alternative
package managers and want to control their configuration.
Github-PR: https://github.com/gentoo/gentoo/pull/69
---
eclass/eutils.eclass | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/eclass/eutils.eclas
On Sat, Sep 5, 2015 at 6:46 AM, Julian Ospald wrote:
> This is particularly useful for people who run alternative
> package managers and want to control their configuration.
I certainly support the principle, but for the sake of transparency
can we try to coordinate this so that the setting name
On 09/05/2015 02:07 PM, Rich Freeman wrote:
> On Sat, Sep 5, 2015 at 6:46 AM, Julian Ospald wrote:
>> This is particularly useful for people who run alternative
>> package managers and want to control their configuration.
>
> I certainly support the principle, but for the sake of transparency
> c
> On Sat, 5 Sep 2015, Rich Freeman wrote:
> I certainly support the principle, but for the sake of transparency
> can we try to coordinate this so that the setting name doesn't
> change when this moves into the package manager for EAPI6?
So far, the EAPI 6 draft says [1]:
eapply_user
T
On 09/05/2015 02:42 PM, Ulrich Mueller wrote:
>> On Sat, 5 Sep 2015, Rich Freeman wrote:
>
>> I certainly support the principle, but for the sake of transparency
>> can we try to coordinate this so that the setting name doesn't
>> change when this moves into the package manager for EAPI6?
>
>
On Sat, Sep 5, 2015 at 8:46 AM, hasufell wrote:
> On 09/05/2015 02:42 PM, Ulrich Mueller wrote:
>>> On Sat, 5 Sep 2015, Rich Freeman wrote:
>>
>>> I certainly support the principle, but for the sake of transparency
>>> can we try to coordinate this so that the setting name doesn't
>>> change w
On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote:
> > On Sat, 5 Sep 2015, Rich Freeman wrote:
>
> > I certainly support the principle, but for the sake of transparency
> > can we try to coordinate this so that the setting name doesn't
> > change when this moves into the package m
On 09/05/2015 06:14 PM, Guilherme Amadio wrote:
> On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote:
>>> On Sat, 5 Sep 2015, Rich Freeman wrote:
>>
>>> I certainly support the principle, but for the sake of transparency
>>> can we try to coordinate this so that the setting name doe
Hi,
I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin
one. We have already dev-rust/cargo package in the rust overlay[2].
It would be logical to have dev-rust/cargo-bin package then. But there
is a problem: it will be the only package in this category in the tree
and it is
On 09/05/2015 02:21 PM, Jauhien Piatlicki wrote:
> Hi,
>
> I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin
> one. We have already dev-rust/cargo package in the rust overlay[2].
>
> It would be logical to have dev-rust/cargo-bin package then. But there
> is a problem: it w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/05/2015 01:04 PM, Matthew Thode wrote:
> On 09/05/2015 02:21 PM, Jauhien Piatlicki wrote:
>> Hi,
>>
>> I have plans to split ?/cargo-bin [1] package from the
>> dev-lang/rust-bin one. We have already dev-rust/cargo package in
>> the rust overl
11 matches
Mail list logo
