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
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
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
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
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
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
>>
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
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: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
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 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 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 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
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
14 matches
Mail list logo
