Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
-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-
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Thu, 6 Sep 2012 01:11:45 -0700
Brian Harring ferri...@gmail.com 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
usual saving/protection of DEPENDENCIES var
else
usual saving/protection of DEPEND/PDEPEND/RDEPEND vars
fi
normal sourcing machinery
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
normal stacking/restoration of DEPENDENCIES rules
else
normal stacking/restoration of RDEPEND/PDEPEND/DEPEND
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] Re: News item 1: changes to stages (make.conf and make.profile)
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] EJOBS variable for EAPI 5?
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] EJOBS variable for EAPI 5?
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?
-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?
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] rfc: netplugd and ifplugd support in OpenRc
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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Tue, 28 Aug 2012 00:23:11 + (UTC) Mike Frysinger (vapier) vap...@gentoo.org 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
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
Re: [gentoo-dev] EJOBS variable for EAPI 5?
On Tue, Sep 11, 2012 at 1:07 PM, Zac Medico zmed...@gentoo.org 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
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] rfc: netplugd and ifplugd support in OpenRc
On Tue, Sep 11, 2012 at 5:01 PM, William Hubbs willi...@gentoo.org 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] [Future EAPI] src_fetch() phase function to support VCS fetching
-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 ferri...@gmail.com 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] [Future EAPI] src_fetch() phase function to support VCS fetching
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 ferri...@gmail.com 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
[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
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] Re: News item 1: changes to stages (make.conf and make.profile)
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
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Tue, Sep 11, 2012 at 7:13 AM, Michał Górny mgo...@gentoo.org wrote:
On Thu, 6 Sep 2012 01:11:45 -0700
Brian Harring ferri...@gmail.com 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
usual saving/protection of DEPENDENCIES var
else
usual saving/protection of DEPEND/PDEPEND/RDEPEND vars
fi
normal sourcing machinery
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
normal stacking/restoration of DEPENDENCIES rules
else
normal stacking/restoration of RDEPEND/PDEPEND/DEPEND
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 depends/rdepends in parallel; they can transition to
pure DEPENDENCIES form at their own pace, dependent on their code, and
the EAPIs they support. At some point we state the transition hack
will be removed in the next EAPI- giving decent forewarning- then
remove it if it's not an undue dev burden. As for eclasses/ebuilds
that are purely =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
[gentoo-portage-dev] app-shells/gentoo-bashcomp needs some portage expert lovin'
Could a number of folks familiar with both portage AND bash completion help out the shell-tools herd (no specific maintainer specified in metadata) with app-shell/gentoo-bashcomp bugs? It seems to have accumulated quite a number (13) of portage-completion (and gentoolkit-completion) related bugs, including bug #424777 filed on July 4th by jer, mentioning that it it breaks with make.conf in /etc/ portage, which is kinda critical right about now. =:^( https://bugs.gentoo.org/show_bug.cgi?id=424777 And here's the list of all open bugs for it. As you can see if you look, all or nearly all of the currently 13 open bugs are portage or gentoolkit related, and it really looks like the package could use some help from those who know those tools. https://bugs.gentoo.org/buglist.cgi?quicksearch=app-shells%2Fgentoo-bashcomp (I said on the devlist thread I'd report bugs, but this one's been open for over two months and is directly related to the make.conf move, so it's a big one, simple fix proposed, but no actual fixes in-tree yet, plus seeing all those others related to portage and gentoolkit, thus the request here.) -- 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
