Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?

2012-09-11 Thread Brian Harring
On Tue, Sep 11, 2012 at 7:13 AM, Michał Górny  wrote:
> On Thu, 6 Sep 2012 01:11:45 -0700
> Brian Harring  wrote:
>
>> A compatibility hack that stacks them is strongly advisable;
>> something akin to the following:
>>
>> Literally, we do the following:
>> inherit() {
>>   if eapi blah; then
>> local DEPEND PDEPEND RDEPEND
>> 
>>   else
>> 
>>   fi
>>   
>>   if eapi blah; then
>> local _deps=( ) _x
>> for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do
>>   [ -n "${!_x}" ] && deps+=( "${!_x}" )
>> done
>> [ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}"
>> unset DEPEND RDEPEND PDEPEND _x _deps
>> 
>>   else
>> 
>>   fi
>> }
>>
>> Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set
>> the DEPENDENCIES directly; those that have to support multiple eapi's
>> (aka, every fricking eclass that exists right now) can just use the
>> old form, shifting into the new form as things progress.
>
> If we decide to go with a such a hack, then we either have to support
> it indefinitely, or to decide to drop the support in some further EAPI.

It's a transitional hack; we support it as long as we need the
transition coverage.  Meaning if by EAPI7, everyone is using EAPI5 and
up (or by EAPI7 it's basicaly insane to try and support
0,1,2,3,4,5,6,7), we drop the transition code in EAPI8.  This is no
different to how RDEPEND/DEPEND autosetting was phased out.

> If we go for the latter, then it's just delaying the ugly conditional
> eclasses will have to suffer at some random point in the future.

Hate to say "na uh", but... na uh.  The point is as long as an eclass
has to support older EAPI's, they can use set DEPEND/RDEPEND and it
would work fine.

If the eclass needs the newer depends types (hdep, fdep, whatever) for
something, it levels an EAPI check, and then sets DEPENDENCIES.
Meanwhile, until it moves it's minimal EAPI to one requiring
DEPENDENCIES, they can use the old syntax and have it stacked.

Basically, either we can have git.eclass (for example) doing:

if has $EAPI 0 1 2 3 4; then
  DEPEND=">=dev-util/git-1.6"
else
  DEPENDENCIES="dep:build? ( >=dev-util/git-1.6 )"
fi

Or, as long as it's suppporting EAPI's 0 1 2 3 4 and the transition is
still enabled for the actual EAPI it's being used in...
DEPEND=">=dev-util/git-1.6"

Doing this means no eclass code has to maintain EAPI5 dependencies
code and =EAPI5, they convert to DEPENDENCIES syntax as they
go/have spare cycles.

Bluntly, this approach makes transition pretty painless for the vast
majority of the tree.  In the grand scheme of things, this is actually
one of the simplest/cleanest migration EAPI will see I suspect.

There really isn't a sane argument to be made against this beyond
"screw it, just make the devs convert immediately and damn the costs"
(which I don't view as sane).

Either way, strongly get the feeling you're arguing purely because it
had the term DEPENDENCIES in it...

~harring



Re: [gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)

2012-09-11 Thread Ben de Groot
On 12 September 2012 08:02, Duncan <1i5t5.dun...@cox.net> wrote:
> Gentoo's bash-completion breaks when make.conf is in /etc/portage.  Bug
> filed back in early July and there's a simple enough patch, but
> app-shells/gentoo-bashcomp has only the shell-tools herd, no dedicated
> maintainer, and 13 open bugs including this one, all apparently portage
> (or gentoolkit) related, with the last release in 2010 (Dec) with
> stabilization a month later.  So it's not seeing a lot of movement.
>
> https://bugs.gentoo.org/show_bug.cgi?id=424777
>
> So anyone who depends on tab-completion for their emerge commands, etc,
> may want to either hold off on the move or apply the patch manually, until
> this is fixed.

Or use zsh instead. You can thank me later. ;-)

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin



[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)

2012-09-11 Thread Duncan
Zac Medico posted on Tue, 11 Sep 2012 09:29:36 -0700 as excerpted:

> I would recommend to simply use /etc/make.conf alone until the legacy
> tools that you use catch up. We have to change the default location in
> the stages in order to expose the bugs so they can get fixed.

I posted to the portage-dev list about this so you probably already know,
but for others, particularly users, following this transition thread:

Gentoo's bash-completion breaks when make.conf is in /etc/portage.  Bug
filed back in early July and there's a simple enough patch, but
app-shells/gentoo-bashcomp has only the shell-tools herd, no dedicated
maintainer, and 13 open bugs including this one, all apparently portage
(or gentoolkit) related, with the last release in 2010 (Dec) with
stabilization a month later.  So it's not seeing a lot of movement.

https://bugs.gentoo.org/show_bug.cgi?id=424777

So anyone who depends on tab-completion for their emerge commands, etc,
may want to either hold off on the move or apply the patch manually, until
this is fixed.

FWIW here's the listing of all open app-shells/gentoo-bashcomp bugs:

https://bugs.gentoo.org/buglist.cgi?quicksearch=app-shells%2Fgentoo-bashcomp

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching

2012-09-11 Thread Brian Harring
On Tue, Sep 11, 2012 at 06:36:46PM -0400, Rick "Zero_Chaos" Farina wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 09/06/2012 02:50 PM, Micha?? G??rny wrote:
> > On Thu, 6 Sep 2012 09:49:13 -0700
> > Brian Harring  wrote:
> > 
> >> One additional thought- re: the scenarios where we don't fetch to an 
> >> intermediate location, then transfer that contents into ${WORKDIR}, 
> >> while a better name is needed, something along the lines of 
> >> RESTRICT=fetches-into-workdir comes to mind.
> 
> Realizing this is a late response I would like to add  Um, what?
> src_fetch should only be putting things into /usr/portage/distfiles,
> never into ${WORKDIR}, that's for src_unpack to handle.
> 
> Am I missing something here?

WORKDIR was an example; punting it directly into the pkgs distfiles is 
also fine.

Basically, you're assuming that the content *is* cachable- cause if it 
isn't, then dumping in ${DISTDIR} is wasteful (both since it'll 
require a copy into the ebuild's workdir, and since it means 
increasing crap accumulating in the workdir).

Further, there are cases where content *is* available, but is 
fundamentally outside ${DISTDIR}- in cros, they have the 
chrome/chromium source available in certain cases.

Now, either we can store 13GB int ${DISTDIR} that's a copy of that 
external developer checkout, then copy that into ${WORKDIR}, or w/ a 
restrict marker, copy that sucker into ${WORKDIR} directly.

Is it a corner case?  Yep, but it's easy enough to deal w/- the only 
constraint there is that the src_fetch's target dir isn't ${DISTDIR}, 
it's ${WORKDIR}, and the PM is required to preserve ${WORKDIR} from 
src_fetch to the time of that pkg actually running.

~harring



Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching

2012-09-11 Thread Rick "Zero_Chaos" Farina
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/06/2012 02:50 PM, Michał Górny wrote:
> On Thu, 6 Sep 2012 09:49:13 -0700
> Brian Harring  wrote:
> 
>> One additional thought- re: the scenarios where we don't fetch to an 
>> intermediate location, then transfer that contents into ${WORKDIR}, 
>> while a better name is needed, something along the lines of 
>> RESTRICT=fetches-into-workdir comes to mind.

Realizing this is a late response I would like to add  Um, what?
src_fetch should only be putting things into /usr/portage/distfiles,
never into ${WORKDIR}, that's for src_unpack to handle.

Am I missing something here?

- -Zero
>>
>> Basically that restriction would be interpretted as "$WORKDIR must be 
>> setup/preserved from invocation of src_fetch to actual building".  
>>
>> Via that restrict, both scenarios should be addressed in full.
> 
> Does separate src_fetch() provide any benefit in that scenario?
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQT7z+AAoJEKXdFCfdEflKVPQQALGcLGAgfo8U+M6TdW5Edksf
oqaXE+NSTeFe2DE0G2mgKYSdSIZgMiFp5mLFwpdfAT1gjzFAc+34+5SY8X/0uaaG
OU7fafdUmOlqgD7rCvX56kSWZVPmTV3oZDghmwB1SUIQpL9PNSZoz5uKoatt4UL8
mBMiTmnsYou8f+wDCJoN8eLVoQb/Hm2inobGUCozCsqU6ASgk1eVePpAmJNNVKp6
wrKuVbj4FeDS17Q6xc2g8exXlkxhGmdS1MmugKBR9csYC9P82fh4bXqVzxG15h9O
YZDU5nagJQ9fY6M7oeKg6etVe6PvwOd/FH0Z4wtQJ2NicOsu6DiBf7J+yLvadJdF
M5fE1kxjtR+rm+6bfNgBl2hP5DPdUYxPnZChftPNRpiVe0P0YZGuRgy+GqfXSmMh
8Zf37hJylauBDy397yGapIJ4ergpYVb3Z1ZfU6uW7n8k0apqjqk+TYLEv2tajtTc
WBdRoBAT1LxvjFIHj2Bf5uzNtqev4l19vJv1AnALgs1v1Z8/TiSPB/B/2DvvIawR
Ys+mAEKzQOCezaCjVOpjq7pvi80/8PMcw6Txk9WpsAezrxdAj2X24kwsptVugCAO
lG3agqmOQgH+vCf0PkplxMSGBlofh4hZ3mNbuDaFlaRfiSlzFX//rkQTtOjK4YQu
6SiRnKxiDzJEn+Q1SNUr
=xgcT
-END PGP SIGNATURE-



Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc

2012-09-11 Thread Rich Freeman
On Tue, Sep 11, 2012 at 5:01 PM, William Hubbs  wrote:
>
> I can agree that a server would probably want a static configuration,
> but all work stations do not use gnome, kde, etc.
>

Most do not run unix, but at work I can't think of any servers that
are using static configurations.  They might be assigned static IPs,
but they'll use DHCP just the same.

I deploy my network at home in the same way - most of my standing PCs
have DNS and static IP assignments, but they still use DHCP.  This way
I can still utilize PXE for backups/etc, and adjust things at any time
fairly easily.

Rich



Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc

2012-09-11 Thread William Hubbs
On Tue, Sep 11, 2012 at 02:43:08PM -0400, Olivier Crête wrote:
> On Tue, 2012-09-11 at 20:01 +0200, Luca Barbato wrote:
> > On 9/10/12 11:05 PM, William Hubbs wrote:
> > > On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote:
> > >> On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote:
> > >>> In researching this program, I have found that it and ifplugd, which is
> > >>> the alternative, have been unmaintained for years. Also Debian has
> > >>> declared netplugd to be obsolete in favor of ifplugd.
> > >>>
> > >>> Does anyone have any thoughts about whether we should keep OpenRC
> > >>> support for one or both of these?
> > >>
> > >> The ifplugd author recommends you use NetworkManager for dynamic
> > >> networking scenarios.
> > >
> > > NM seems bloated though unless you are using a desktop environment. It
> > > wants to install 29 dependencies on my box.
> > 
> > NM and connman are quite a bit overkill indeed.
> 
> If you're on a server, you probably want a static configuration anyway,
> not something dynamic.

I can agree that a server would probably want a static configuration,
but all work stations do not use gnome, kde, etc.

William



pgpLytOppCMKG.pgp
Description: PGP signature


Re: [gentoo-dev] EJOBS variable for EAPI 5?

2012-09-11 Thread Rich Freeman
On Tue, Sep 11, 2012 at 1:07 PM, Zac Medico  wrote:
> On 09/11/2012 09:54 AM, Ian Stakenvicius wrote:
>> At the ebuild level, certainly, but that's one of the reasons for
>> EJOBS in the first place, so that it can be overridden consistently
>> within a phase, if necessary for the ebuild (regardless of build
>> system type), right?
>
> Right. I'm surprised that ELOADAVG wasn't proposed in tandem with EJOBS
> though, since overloading is not a good idea, and can happen easily any
> time that you doing lots of things in parallel.

I tend to agree that load average matters more, although that doesn't
factor in RAM use.

I don't suggest that this is something that is easily remedied, but I
have run into a situation where WHAT you're doing greatly influences
how many jobs you can run - distcc.  I once tried to implement distcc
in a fairly large cluster, and then run make with VERY high levels of
parallelization - such as -j32.  That worked great - if the package
used C.  Then portage would try to build something that used ant and
suddenly the host was trying to run 32 jvms in parallel - just killing
the system.  Ditto for python/etc.  There was no way to tell the build
system to go nuts with anything using distcc but not everything else.

I think this is just a fundamental limitation of make - I don't
suggest that we can fix this at the portage level.  However, that is a
use case where WHAT you're doing influences how many jobs you can run.

Rich



Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc

2012-09-11 Thread Olivier Crête
On Tue, 2012-09-11 at 20:01 +0200, Luca Barbato wrote:
> On 9/10/12 11:05 PM, William Hubbs wrote:
> > On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote:
> >> On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote:
> >>> In researching this program, I have found that it and ifplugd, which is
> >>> the alternative, have been unmaintained for years. Also Debian has
> >>> declared netplugd to be obsolete in favor of ifplugd.
> >>>
> >>> Does anyone have any thoughts about whether we should keep OpenRC
> >>> support for one or both of these?
> >>
> >> The ifplugd author recommends you use NetworkManager for dynamic
> >> networking scenarios.
> >
> > NM seems bloated though unless you are using a desktop environment. It
> > wants to install 29 dependencies on my box.
> 
> NM and connman are quite a bit overkill indeed.

If you're on a server, you probably want a static configuration anyway,
not something dynamic.

-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

2012-09-11 Thread Alexis Ballier
On Tue, 28 Aug 2012 00:23:11 + (UTC)
"Mike Frysinger (vapier)"  wrote:

> vapier  12/08/28 00:23:11
> 
>   Modified: ChangeLog profiles.desc
>   Log:
>   add new s390x profile #345421

[...]

> @@ -152,7 +153,7 @@
>  x86 default/linux/x86/10.0/server
> stable 
>  # Gentoo/FreeBSD Profiles
> -amd64-fbsd   default/bsd/fbsd/amd64/9.0 stable
> +amd64-fbsd   default/bsd/fbsd/amd64/9.0 dev
> sparc-fbsddefault/bsd/fbsd/sparc/8.2 exp
> x86-fbsd  default/bsd/fbsd/x86/8.2   dev
> x86-fbsd  default/bsd/fbsd/x86/9.0   dev

please be more careful, it is good practice to review the cvs diff output 
before hitting ci when committing to the profiles or eclass directories.

A.



Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc

2012-09-11 Thread Luca Barbato

On 9/10/12 11:05 PM, William Hubbs wrote:

On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote:

On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote:

In researching this program, I have found that it and ifplugd, which is
the alternative, have been unmaintained for years. Also Debian has
declared netplugd to be obsolete in favor of ifplugd.

Does anyone have any thoughts about whether we should keep OpenRC
support for one or both of these?


The ifplugd author recommends you use NetworkManager for dynamic
networking scenarios.


NM seems bloated though unless you are using a desktop environment. It
wants to install 29 dependencies on my box.


NM and connman are quite a bit overkill indeed.

lu




Re: [gentoo-dev] EJOBS variable for EAPI 5?

2012-09-11 Thread Zac Medico
On 09/11/2012 09:54 AM, Ian Stakenvicius wrote:
> On 11/09/12 12:43 PM, Zac Medico wrote:
>> On 09/11/2012 09:36 AM, viv...@gmail.com wrote:
>>> Dunno where to place this request, but if we go for something
>>> like EJOBS could we also make it phase specific? So compile,
>>> install and test could have a different number of jobs running. 
>>> Possibly three different variables that override a predefined
>>> EJOBS.
> 
>> Per-phase sounds a little to fine-grained. Instead, I'd suggest to
>> add an ELOADAVG variable that's analogous to make's --load-average
>> option. That should be enough to compensate for any differences
>> between phases.
> 
> I personally wonder about why this would be necessary from the
> perspective of the user; if the user's system at emerge time can
> handle X concurrent processes per emerge-job , i don't see why it
> would matter what phase these jobs would be launched from.

Right, what matters is the system load, which is why I suggested ELOADAVG.

> At the ebuild level, certainly, but that's one of the reasons for
> EJOBS in the first place, so that it can be overridden consistently
> within a phase, if necessary for the ebuild (regardless of build
> system type), right?

Right. I'm surprised that ELOADAVG wasn't proposed in tandem with EJOBS
though, since overloading is not a good idea, and can happen easily any
time that you doing lots of things in parallel.
-- 
Thanks,
Zac



Re: [gentoo-dev] EJOBS variable for EAPI 5?

2012-09-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/09/12 12:43 PM, Zac Medico wrote:
> On 09/11/2012 09:36 AM, viv...@gmail.com wrote:
>> Dunno where to place this request, but if we go for something
>> like EJOBS could we also make it phase specific? So compile,
>> install and test could have a different number of jobs running. 
>> Possibly three different variables that override a predefined
>> EJOBS.
> 
> Per-phase sounds a little to fine-grained. Instead, I'd suggest to
> add an ELOADAVG variable that's analogous to make's --load-average
> option. That should be enough to compensate for any differences
> between phases.

I personally wonder about why this would be necessary from the
perspective of the user; if the user's system at emerge time can
handle X concurrent processes per emerge-job , i don't see why it
would matter what phase these jobs would be launched from.

At the ebuild level, certainly, but that's one of the reasons for
EJOBS in the first place, so that it can be overridden consistently
within a phase, if necessary for the ebuild (regardless of build
system type), right?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBPbLEACgkQ2ugaI38ACPA1qAD/bvjy7aB6nk5YboJHnCpQ8C56
QolKD9BPHL9eN8Xf41oA/iTZU+tyB+BDl+woZAlVGbaa6AR2r6Qp8rwOzkUWSwV/
=FhKc
-END PGP SIGNATURE-



Re: [gentoo-dev] EJOBS variable for EAPI 5?

2012-09-11 Thread Zac Medico
On 09/11/2012 09:36 AM, viv...@gmail.com wrote:
> Dunno where to place this request, but if we go for something like EJOBS
> could we also make it phase specific?
> So compile, install and test could have a different number of jobs running.
> Possibly three different variables that override a predefined EJOBS.

Per-phase sounds a little to fine-grained. Instead, I'd suggest to add
an ELOADAVG variable that's analogous to make's --load-average option.
That should be enough to compensate for any differences between phases.
-- 
Thanks,
Zac



Re: [gentoo-dev] EJOBS variable for EAPI 5?

2012-09-11 Thread viv...@gmail.com

Il 04/09/2012 19:15, Zac Medico ha scritto:

On 09/04/2012 04:00 AM, Walter Dnes wrote:

On Sat, Sep 01, 2012 at 05:20:02PM -0700, Brian Harring wrote


This approach is fine imo, although I'd *potentially* look at adding a
magic $PROC_COUNT var that is the # of cpu threads on the system;
either that or defaulting jobs to it.

I rather dislike requiring users to go jam a 2/4/8 in there when it's
easy to compute.  That said, it's minor.

Either way, yes, I think EJOBS should be in EAPI5.

   One question about the suggested EJOBS variable; will it over-ride
MAKEOPTS?  Every so often on the Gentoo-user list, someone comes along
with a mysterious build failure.  The first suggestion is to reset
MAKEOPTS to -j1.  And on some occasions, that is indeed the solution to
the mysterious build failure.

That would be due to a missing dependency in the Makefiles, and using
-j1 is just a workaround. The ebuild can be hardcoded to use emake -j1
until the Makefile gets fixed.


   I set -j1 and leave it that way.  Yes, the builds take longer, but the
resulting binary is just as fast.  And the amount of time I "save" will
be blown away the first time I end up screwing around a couple of hours
trying to fix a mysterious build failure.  That's why I want the user to
have the option of over-riding EJOBS, should it ever be implemented.

You could use EXTRA_EMAKE for that. You can do per-package settings via
/etc/portage/package.env.


Dunno where to place this request, but if we go for something like EJOBS 
could we also make it phase specific?

So compile, install and test could have a different number of jobs running.
Possibly three different variables that override a predefined EJOBS.

TIA




Re: [gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)

2012-09-11 Thread Zac Medico
On 09/10/2012 08:29 PM, Gregory M. Turner wrote:
> On 9/9/2012 6:34 PM, Zac Medico wrote:
>> On 09/09/2012 05:59 PM, Duncan wrote:
>>> To your knowlege (IOW have you tested) having /etc/make.conf either a
>>> symlink to /etc/portage/make.conf or a simple one-line
>>> "source /etc/portage/make.conf"?
>>
>> I've tested them both just now, and they work for me. Why wouldn't they?
> 
> If both /etc/portage/make.conf and /etc/make.conf were evaluated, stuff
> like
> 
>   FOO="${FOO} bar"
> 
> could cause, i.e., duplications... not sure what all the rules are
> limiting what one can and can't put in make.conf, but one could imagine
> all kinds of wacky stuff.

It could cause duplicates, but for variables where FOO="${FOO} bar"
makes sense, duplicates probably aren't harmful.

> However, IIRC, /etc/make.conf is just ignored by portage if
> /etc/portage/make.conf is present,

I don't know where you got that idea, but it's not true. Portage sources
both files, and settings from /etc/portage/make.conf will override
settings from /etc/make.conf.

> so symlinking, or even better, if
> possible, hardlinking those files would probably "do the right thing"
> for legacy tools that don't know about the new location... unless I'm
> mistaken, which is always plausible :)

I would recommend to simply use /etc/make.conf alone until the legacy
tools that you use catch up. We have to change the default location in
the stages in order to expose the bugs so they can get fixed.
-- 
Thanks,
Zac



Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?

2012-09-11 Thread Michał Górny
On Thu, 6 Sep 2012 01:11:45 -0700
Brian Harring  wrote:

> A compatibility hack that stacks them is strongly advisable;
> something akin to the following:
> 
> Literally, we do the following:
> inherit() {
>   if eapi blah; then
> local DEPEND PDEPEND RDEPEND
> 
>   else
> 
>   fi
>   
>   if eapi blah; then
> local _deps=( ) _x
> for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do
>   [ -n "${!_x}" ] && deps+=( "${!_x}" )
> done
> [ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}"
> unset DEPEND RDEPEND PDEPEND _x _deps
> 
>   else
> 
>   fi
> }
> 
> Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set 
> the DEPENDENCIES directly; those that have to support multiple eapi's 
> (aka, every fricking eclass that exists right now) can just use the 
> old form, shifting into the new form as things progress.

If we decide to go with a such a hack, then we either have to support
it indefinitely, or to decide to drop the support in some further EAPI.

If we go for the latter, then it's just delaying the ugly conditional
eclasses will have to suffer at some random point in the future. Well,
maybe two eclasses less if we wait with it for an EAPI which will
provide 'killer features' which will render the eclasses unusable with
older EAPIs. And way, it will be a bit confusing to remember two switch
points...

If we go for the former... then some developers will ask: why eclasses
and not ebuilds? Why?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc

2012-09-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/09/12 04:05 PM, David Leverton wrote:
> 4) dhcpcd: not sure when it was introduced, but current dhcpcd can 
> detect when the link goes up and down, and request/renew its lease 
> when it comes up.  The only wrinkle that I can see here is that, if
> no ifplugd/netplug/wpa_supplicant is configured, OpenRC waits for
> it to receive a lease when starting the interface, rather than
> allowing it to background itself.
> 
> So for dhcpcd, it might be enough to just make OpenRC aware that
> it doesn't need to wait for a lease when starting the interface.

According to bug 253925 , this would only work for certain hardware
(ie, those that support the IFF_RUNNING method); ifplugd suppots three
methods (IFF_RUNNING, ethtool-style, mii-style), and netplug -seems-
to do it by connecting at the netlink level to the interface and just
listening for traffic (as far as I can tell).  So for link detection,
both ifplugd and netplug would be better than attempting to just use
dhcpcd, imo (not to mention the non-dhcp-based configs)..

(plus, since this is all for oldnet only, i would expect dhcpcd would
be a bit of an issue to integrate so that it would be able to move
net.* from inactive to started state and then exclude it from being
run a second time to configure the now-up iface..)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBPOVcACgkQ2ugaI38ACPBevgD+LN73S/g6aQ8D2sR4rrIjNkSd
3eP1KgcGoEFeU+yPFIcA/RyC/fShiEaLiATnxN0ybymqspMQQcSrLj4GxeMqnPfs
=jpCo
-END PGP SIGNATURE-