I just noticed this after upgrading to 2.2_rc29, and confirmed the issue with scarabeus. With PORTAGE_ECLASS_WARNING_ENABLE="1" set, we get the following difference in kdeprefix useflag (disabled by kde-testing/eclass/kde4-base.eclass for non kde-base category packages): 2.2_rc28, as expected: # emerge -pv ktorrent * Overlay eclasses override eclasses from PORTDIR: * * '/var/repos/kde-testing/eclass/kde4-base.eclass' * '/var/repos/kde-testing/eclass/kde4-functions.eclass' * '/var/repos/kde-testing/eclass/kde4-meta.eclass' * * It is best to avoid overriding eclasses from PORTDIR because it will * trigger invalidation of cached ebuild metadata that is distributed with * the portage tree. If you must override eclasses from PORTDIR then you * are advised to add FEATURES="metadata-transfer" to /etc/make.conf and to * run `emerge --regen` after each time that you run `emerge --sync`. Set * PORTAGE_ECLASS_WARNING_ENABLE="0" in /etc/make.conf if you would like to * disable this warning. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-p2p/ktorrent-3.2.1 USE="bwscheduler downloadorder infowidget ipfilter kross logviewer mediaplayer scanfolder search stats upnp zeroconf -debug -plasma -rss -webinterface" LINGUAS="en_GB -ar -be -bg -ca -cs -da -de -el -es -et -fr -ga -gl -hi -it -ja -km -lt -lv -nb -nds -nl -nn -oc -pl -pt -pt_BR -ro -ru -se -sk -sl -sr -sv -tr -uk -zh_CN -zh_TW" 0 kB And with 2.2_rc29: # emerge -pv ktorrent These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-p2p/ktorrent-3.2.1 USE="bwscheduler downloadorder infowidget ipfilter kdeprefix%* kross logviewer mediaplayer scanfolder search stats upnp zeroconf -debug -plasma -rss -webinterface" LINGUAS="en_GB -ar -be -bg -ca -cs -da -de -el -es -et -fr -ga -gl -hi -it -ja -km -lt -lv -nb -nds -nl -nn -oc -pl -pt -pt_BR -ro -ru -se -sk -sl -sr -sv -tr -uk -zh_CN -zh_TW" 0 kB rc29 does not show the warning that eclasses are overridden, and as a result adds the kdeprefix useflag (according to portage eclass, but is disabled in overlay eclass).
ktorrent-3.2.1 is in main tree. If the ebuild you are talking about is in main tree, then the behavior of portage seems to be correct. Unless this also happens for ebuilds from the same overlay as the eclass.
(In reply to comment #1) > ktorrent-3.2.1 is in main tree. If the ebuild you are talking about is in main > tree, then the behavior of portage seems to be correct. Unless this also > happens for ebuilds from the same overlay as the eclass. > You have to be kidding me that you are going to disable eclass overriding for main tree. How are we supposed to develop the eclasses now, hm?
(In reply to comment #1) > ktorrent-3.2.1 is in main tree. If the ebuild you are talking about is in main > tree, then the behavior of portage seems to be correct. That would mean this is now a "feature". But this is a change from previous behavior... (In reply to comment #2) > How are we supposed to develop the eclasses now, hm? The same way we do on qting-edge: give it a unique name as long as it is in overlay. Then you can add it to you local cvs portage checkout for testing when you are ready to move it to the tree. (Not saying this is ideal, but it works for us.)
If this is intended behavior, perhaps it would make sense to add a parameter to portage that enables devs to override this?
> (In reply to comment #2) > > How are we supposed to develop the eclasses now, hm? > > The same way we do on qting-edge: give it a unique name as long as it is in > overlay. Then you can add it to you local cvs portage checkout for testing when > you are ready to move it to the tree. (Not saying this is ideal, but it works > for us.) > Not nice. If i would like the current behavior i would rename the eclasses in the first place. I wanted it to override the portage one. We need to test various packages from the tree before puting the eclass in. And for that is actualy quite annoying to copy more than 250 ebuilds for testing into the overlay.
Well, we have a bit more ebuilds inheriting kde4-base, kde4-meta eclasses than any other overlay...
This behaviour should be switchable anyway, so that if we're going to test overlay eclassess, we could tell users to allow eclass overriding and as well to be able to tell them to go to hell if they report issues with overlay not having eclass overriding enabled.
Sorry for my inability to read ChangeLog in time: bug 124041
Wher to put the layout.conf to override the eclasses in portage? Put it in overlay/metadata did't work. cat layout.conf masters = overlay gentoo
(In reply to comment #2) > How are we supposed to develop the eclasses now, hm? I think I'll add support for /etc/portage/repos.conf which will have an INI format (like sets.conf) that will allow you to override eclasses for the gentoo repo like this: [gentoo] eclass-overrides = java-overlay java-experimental The above setting will cause eclasses from java-overlay and java-experimental to override eclasses from the main repo, and eclasses from java-experimental will have precedence over eclasses from java-overlay.
(In reply to comment #10) > (In reply to comment #2) > > How are we supposed to develop the eclasses now, hm? > > I think I'll add support for /etc/portage/repos.conf which will have an INI > format (like sets.conf) that will allow you to override eclasses for the gentoo > repo like this: > > [gentoo] > eclass-overrides = java-overlay java-experimental > > The above setting will cause eclasses from java-overlay and java-experimental > to override eclasses from the main repo, and eclasses from java-experimental > will have precedence over eclasses from java-overlay. > Zac it is nice, but you will potentialy break any kde overlay consumers. Could it be specified somewhere on the overlay directory structure?
(In reply to comment #11) > (In reply to comment #10) ... > > I think I'll add support for /etc/portage/repos.conf which will have an INI > > format (like sets.conf) that will allow you to override eclasses for the gentoo > > repo like this: > > > > [gentoo] > > eclass-overrides = java-overlay java-experimental > > > > The above setting will cause eclasses from java-overlay and java-experimental > > to override eclasses from the main repo, and eclasses from java-experimental > > will have precedence over eclasses from java-overlay. > > > Zac it is nice, but you will potentialy break any kde overlay consumers. > Could it be specified somewhere on the overlay directory structure? Thomas, even though this means more work for maintainers and users, to keep the QA assurance that this change purports to do, any override may not be done inside an overlay - otherwise, we're allowing overlays to override the tree without any intervention from the user. Zac, it looks good, but given the discussion in #gentoo-portage, wouldn't it be better to create a complete solution, instead of creating one just for eclasses? We'll soon be talking about ebuilds and profiles/*.
(In reply to comment #12) > even though this means more work for maintainers and users, to keep the QA > assurance that this change purports to do, any override may not be done inside > an overlay - otherwise, we're allowing overlays to override the tree without > any intervention from the user. I agree. Letting the overlay override it beats the purpose of this new feature. BTW, my initial bug report was for the sudden change in behavior. You have to really dig deeper to find out this was intentional.
Created attachment 188036 [details, diff] add support for /etc/portage/repos.conf which allows eclass overrides Add a new /etc/portage/repos.conf config file which can be used to configure site-specific eclass override behavior. Note that configuration settings which are specified here do not apply to tools such as repoman(1) and egencache(1) since their operations are inherently not site-specific. Beware that use of eclass-overrides is generally not recommended and that it may trigger performance issues under some circumstances (see bug #124041). Example: # make all repositories inherit eclasses from the java-overlay and # java-experimental repositories, with eclasses from java-experimental # taking precedence over those from java-overlay [DEFAULT] eclass-overrides = java-overlay java-experimental # disable all eclass overrides for the gentoo repository [gentoo] eclass-overrides = (In reply to comment #12) > it looks good, but given the discussion in #gentoo-portage, wouldn't it be > better to create a complete solution, instead of creating one just for > eclasses? We'll soon be talking about ebuilds and profiles/*. As said on irc, right now I'm mainly concerned about providing eclass override configuration for those who demand it (due to issues like bug #124041 it's considered an 'advanced' feature that's not intended for most users). We can extend repos.conf later to add more attributes to as necessary.
Created attachment 188038 [details, diff] fix fail in man/portage.5
(In reply to comment #11) > Zac it is nice, but you will potentialy break any kde overlay consumers. > Could it be specified somewhere on the overlay directory structure? I'm not sure what your intention is but maybe you can use metadata/layout.conf for what you're trying to do. In case you're not familiar with it, it's documented in the portage(5) man page and this is where the idea came from: http://archives.gentoo.org/gentoo-dev/msg_33c61550b4ed2b7b25dd5a4110e1ec81.xml
This is fixed in 2.2_rc30.
The [DEFAULT] handling had a bug in 2.2_rc31, and it's fixed in 2.2_rc32 (svn r13578).
It seems the eclass override functionality is broken in 2.2_rc48, we have been unable to get this working and override eclasses in the main gentoo tree with our own overlay eclasses as we normally do with 2.1.6.7
(In reply to comment #19) > It seems the eclass override functionality is broken in 2.2_rc48, we have been > unable to get this working and override eclasses in the main gentoo tree with > our own overlay eclasses as we normally do with 2.1.6.7 You probably just need to configure eclass-overrides, as documented in `man 5 portage`.
we already have /etc/portage/repos.conf setup as described in this report and man portage our overlay is named noc4 [gentoo] eclass-overrides = noc4 [DEFAULT] eclass-overrides = noc4 (In reply to comment #20) > (In reply to comment #19) > > It seems the eclass override functionality is broken in 2.2_rc48, we have been > > unable to get this working and override eclasses in the main gentoo tree with > > our own overlay eclasses as we normally do with 2.1.6.7 > > You probably just need to configure eclass-overrides, as documented in `man 5 > portage`. >
(In reply to comment #21) Please file a new bug. This output of this command should give us some helpful debugging info: python -c 'import portage ; print [(x, \ portage.portdb._repo_info[x].eclass_db.porttrees) for x in \ portage.portdb._repo_info]'
