On Fri, 12 Oct 2012 21:10:23 -0600
Ryan Hill wrote:
> I'd argue against deprecating EAPI 0 any time soon though. Killing
> EAPI 1 would be a better idea.
I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be
gone from tree in 3-5 years once the EAPI=0 requirement is lifted.
Cur
On Fri, 12 Oct 2012 12:53:15 +0200
Ralph Sennhauser wrote:
> The EAPI=0 requirement comes from having to provide an update path for
> systems with a package manager without EAPI support. By now we are
> talking about really ancient systems and it's questionable if there is
> any merit in supporti
On Fri, 2012-10-12 at 16:38 -0400, Walter Dnes wrote:
> It's my understanding that higher EAPI levels include more features.
> How backwards compatable are the EAPI levels? I.e. assume that we take
> an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top,
> without any other chang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/10/12 04:38 PM, Walter Dnes wrote:
> On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
>> From time to time the topic of deprecating EAPIs comes up and
>> usually one suggestion is to keep 0 and start with converting
>> EAPI 1 eb
On Fri, 12 Oct 2012 16:38:06 -0400
"Walter Dnes" wrote:
> On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
> > From time to time the topic of deprecating EAPIs comes up and
> > usually one suggestion is to keep 0 and start with converting EAPI
> > 1 ebuilds. Then someone comes alon
On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
> From time to time the topic of deprecating EAPIs comes up and usually
> one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
> Then someone comes along and asks what is the point? Indeed, a fair
> question.
It's
Markos Chandras schrieb am 12.10.2012 10:08:
>
> +1. I want these profiles to *staty*. I am using this profile on my
> "home boxes". It is the most minimal profile as the rest of the
> profiles pull in too much useless stuff. What is wrong with these
> profiles anyway?
>
If you want a minimal pr
This is why I said that the server profile are no lighter than the base.
It's actually the base PLUS "snmp truetype xml".
My original suggestion of hiding or removing the server profiles was based
on the assumption that no one wants to maintain it. The server profiles
*in their current state* ar
On Fri, Oct 12, 2012 at 4:18 AM, Rich Freeman wrote:
> On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras wrote:
>> +1. I want these profiles to *staty*. I am using this profile on my
>> "home boxes". It is the most minimal profile as the rest of the
>> profiles pull in too much useless stuff. What
On Fri, Oct 12, 2012 at 8:46 AM, Sergey Popov wrote:
> Indeed. Hardened server profile does not fit in all cases, some
> non-hardened server profile should exist, BUT without this warning(if
> it's usable, of course), and probably with better support.
Well, support is mainly a matter of people st
11.10.2012 23:22, Mike Frysinger wrote:
> On Thursday 11 October 2012 14:56:11 Ben Kohler wrote:
>> I would like to suggest that the "server" profile variants
>> (ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so
>> that they do not show up in "eselect profile list" for new use
On Fri, 12 Oct 2012 13:35:44 +0300
Reinis Danne wrote:
> On Mon, Oct 08, 2012 at 05:16:05PM +0200, Michał Górny wrote:
> > Hello,
> >
> > This is the second and hopefully last version of python-r1 +
> > distutils-r1 eclasses before committing. I would also like to shortly
> > point out the goals
On 10/11/2012 3:31 PM, Ben Kohler wrote:
There are other ways to achieve a "lighter" system, but that's not really
what this is about. The server profiles are not any lighter than the base
profiles.
To those in favor of keeping some kind of "server" profile around, how
would it differ from the
On 10/11/2012 2:40 PM, Marien Zwart wrote:
I'm going to do something potentially rude and comment on this without
having read the entire thread.
On Thu, Oct 11, 2012 at 10:39 PM, Gregory M. Turner wrote:
Anyhow one thing I have figured out is how things can work correctly on
Linux wihtout -L.:
From time to time the topic of deprecating EAPIs comes up and usually
one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
Then someone comes along and asks what is the point? Indeed, a fair
question.
The following tries to take a different approach to the topic. It's not
all thou
On Mon, Oct 08, 2012 at 05:16:05PM +0200, Michał Górny wrote:
> Hello,
>
> This is the second and hopefully last version of python-r1 +
> distutils-r1 eclasses before committing. I would also like to shortly
> point out the goals and the differences between various python eclasses
> in Gentoo.
>
On Fri, Oct 12, 2012 at 9:18 AM, Rich Freeman wrote:
> On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras wrote:
>> +1. I want these profiles to *staty*. I am using this profile on my
>> "home boxes". It is the most minimal profile as the rest of the
>> profiles pull in too much useless stuff. What
On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras wrote:
> +1. I want these profiles to *staty*. I am using this profile on my
> "home boxes". It is the most minimal profile as the rest of the
> profiles pull in too much useless stuff. What is wrong with these
> profiles anyway?
Looking at the act
On Thu, Oct 11, 2012 at 9:04 PM, Walter Dnes wrote:
> On Thu, Oct 11, 2012 at 03:22:17PM -0400, Mike Frysinger wrote
>
>> sounds like something to fix rather than punt. i don't know why
>> you think having server profiles is "undesirable", but i certainly
>> desire it on many systems. like serve
On Thu, Oct 11, 2012 at 8:22 PM, Mike Frysinger wrote:
> On Thursday 11 October 2012 14:56:11 Ben Kohler wrote:
>> I would like to suggest that the "server" profile variants
>> (ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so
>> that they do not show up in "eselect profile l
20 matches
Mail list logo
