The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2007-11-11 23h59 UTC.
Removals:
app-editors/pico2007-11-05 15:03:12 drac
x11-wm/beryl2007-11-06 01:02:53 hanno
x11-w
On Sonntag, 11. November 2007, Ciaran McCreesh wrote:
> I suspect that for existing eclasses, the safest way to proceed is to
> make a new eclass and move common code into a third eclass. So you'd
> have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
> and foo-eapi1.eclass doing
On Sun, 11 Nov 2007 21:50:05 +0100
Fabian Groffen <[EMAIL PROTECTED]> wrote:
> In this setting, one could say that eclasses should remain EAPI=0,
> such that all ebuilds will be able to work with them.
Mm. Slight problem with wording here, which is causing confusion.
Eclasses don't have an EAPI.
On 11-11-2007 19:27:50 +, Ciaran McCreesh wrote:
> On Sun, 11 Nov 2007 21:21:30 +0200
> Petteri Räty <[EMAIL PROTECTED]> wrote:
> > > Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to
> > > 'die' at global scope. There's simply no way for eclasses to
> > > complain that they're b
On Fri, 9 Nov 2007 22:40:08 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> Is the following set sufficient? Is the following set the least
> restrictive correct solution?
... to explain the implications of these...
Say we have packages a, b and c, and none of them have any
dependencies. One v
On Sun, 11 Nov 2007 21:21:30 +0200
Petteri Räty <[EMAIL PROTECTED]> wrote:
> > Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to
> > 'die' at global scope. There's simply no way for eclasses to
> > complain that they're being misused.
>
> Well nothing formal but the ebuild developer
Ciaran McCreesh kirjoitti:
> On Sun, 11 Nov 2007 21:01:41 +0200
> Petteri Räty <[EMAIL PROTECTED]> wrote:
>> If we go with this solution then I guess eclasses must check for the
>> EAPI variable and then act accordingly. For example if the ebuild sets
>> EAPI=2 and the eclass is designed for EAPI=1
On Sun, 11 Nov 2007 21:01:41 +0200
Petteri Räty <[EMAIL PROTECTED]> wrote:
> If we go with this solution then I guess eclasses must check for the
> EAPI variable and then act accordingly. For example if the ebuild sets
> EAPI=2 and the eclass is designed for EAPI=1 then it could be made to
> die in
Fabian Groffen kirjoitti:
> On 09-11-2007 23:55:51 +0200, Petteri Räty wrote:
>> Usually it's best that ebuild variables follow the order that is in
>> skel.ebuild. So know we should decide where to place EAPI. I suggest we
>> put it it after LICENSE as that's where the more technical stuff like
>>
app-text/cstetex has been p.masked for removal in 30 days.
# Alexis Ballier <[EMAIL PROTECTED]> (11 Nov 2007)
# Lots of security issues: bug #196673
# The experience with babel in tetex-3, texlive
# and xetex is good. Skilled users recommended to migrate.
# Masking for removal: Due 11 Dec 2007
On Sun, 11 Nov 2007 09:43:49 +
Steve Long <[EMAIL PROTECTED]> wrote:
> > Which is just as bad.
> >
> No, it's better for the reason given: it doesn't require login as
> root.
And it's still checking the wrong thing.
> Use of ((EUID)) is also quicker.
Quicker than what? It's quicker than the
Steve Long <[EMAIL PROTECTED]>:
> Ciaran McCreesh wrote:
> > Steve Long <[EMAIL PROTECTED]> wrote:
> >> I've always used EUID for the root check, eg:
> > Which is just as bad.
> No, it's better for the reason given: it doesn't require login as
> root. Use of ((EUID)) is also quicker.
Capabilites
William L. Thomson Jr. wrote:
> On Sat, 2007-11-10 at 18:36 +0100, Bo Ørsted Andresen wrote:
>> On Sat, Nov 10, 2007 at 11:51:37AM +0100, Krzysiek Pawlik wrote:
>> > It's purpose is to remove the ${D} from makefile, additionally ${D} is
>> > in single quotes, so it will not be expanded - is it a bu
Ciaran McCreesh wrote:
> On Thu, 08 Nov 2007 18:22:48 +
> Steve Long <[EMAIL PROTECTED]> wrote:
>> > if [[ ${UID} -ne 0 ]]; then
>> >
>> > We've always told people not to do that. Capabilities required by
>> > eselect modules should be tested by attempting to perform the
>> > action, not by so
14 matches
Mail list logo
