Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 265747 - sys-apps/portage-2.2_rc29 does not let overlays override eclasses
Summary: sys-apps/portage-2.2_rc29 does not let overlays override eclasses
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 210077 268228
  Show dependency tree
 
Reported: 2009-04-11 11:17 UTC by Ben de Groot (RETIRED)
Modified: 2011-12-25 14:58 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
add support for /etc/portage/repos.conf which allows eclass overrides (eclass_overrides.patch,5.82 KB, patch)
2009-04-12 00:02 UTC, Zac Medico
Details | Diff
fix fail in man/portage.5 (eclass_overrides.patch,5.81 KB, patch)
2009-04-12 00:52 UTC, Magnus Granberg
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ben de Groot (RETIRED) gentoo-dev 2009-04-11 11:17:28 UTC
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).
Comment 1 Marijn Schouten (RETIRED) gentoo-dev 2009-04-11 11:29:11 UTC
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.
Comment 2 Tomáš Chvátal (RETIRED) gentoo-dev 2009-04-11 12:59:18 UTC
(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?
Comment 3 Ben de Groot (RETIRED) gentoo-dev 2009-04-11 13:08:36 UTC
(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.)
Comment 4 R Bar-On 2009-04-11 13:12:37 UTC
If this is intended behavior, perhaps it would make sense to add a parameter to portage that enables devs to override this?
Comment 5 Tomáš Chvátal (RETIRED) gentoo-dev 2009-04-11 13:13:38 UTC
> (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.
Comment 6 Maciej Mrozowski gentoo-dev 2009-04-11 13:15:26 UTC
Well, we have a bit more ebuilds inheriting kde4-base, kde4-meta eclasses than any other overlay...
Comment 7 Maciej Mrozowski gentoo-dev 2009-04-11 13:26:07 UTC
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.
Comment 8 Maciej Mrozowski gentoo-dev 2009-04-11 13:33:01 UTC
Sorry for my inability to read ChangeLog in time:
bug 124041
Comment 9 Magnus Granberg gentoo-dev 2009-04-11 15:13:34 UTC
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

Comment 10 Zac Medico gentoo-dev 2009-04-11 19:55:52 UTC
(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.
Comment 11 Tomáš Chvátal (RETIRED) gentoo-dev 2009-04-11 20:03:59 UTC
(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?
Comment 12 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2009-04-11 20:13:13 UTC
(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/*.
Comment 13 Ben de Groot (RETIRED) gentoo-dev 2009-04-11 20:21:32 UTC
(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.
Comment 14 Zac Medico gentoo-dev 2009-04-12 00:02:17 UTC
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.
Comment 15 Magnus Granberg gentoo-dev 2009-04-12 00:52:34 UTC
Created attachment 188038 [details, diff]
fix fail in man/portage.5
Comment 16 Zac Medico gentoo-dev 2009-04-12 05:09:40 UTC
(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
Comment 17 Zac Medico gentoo-dev 2009-04-12 06:21:48 UTC
This is fixed in 2.2_rc30.
Comment 18 Zac Medico gentoo-dev 2009-05-02 07:59:31 UTC
The [DEFAULT] handling had a bug in 2.2_rc31, and it's fixed in 2.2_rc32 (svn r13578).
Comment 19 Paul Freeman 2009-11-04 15:30:32 UTC
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
Comment 20 Zac Medico gentoo-dev 2009-11-04 21:06:07 UTC
(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`.
Comment 21 Paul Freeman 2009-11-04 22:30:53 UTC
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`.
> 

Comment 22 Zac Medico gentoo-dev 2009-11-05 07:02:52 UTC
(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]'