| Summary: | profilever() function does not show top level parent. (emerge -V) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | solar (RETIRED) <solar> |
| Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I don't get what you are saying here. What does /etc/make.profile point to? /etc/make.profile -> ../var/cvsroot/gentoo-x86/profiles/hardened/x86 If we follow the orders of profiles. hardened/x86 / $ cd /var/cvsroot/gentoo-x86/profiles/hardened/x86/ / x86 $ grep -v -e ^$ -e ^# parent .. x86 $ cd .. hardened $ grep -v -e ^$ -e ^# parent ../base hardened $ cd ../base/ base $ grep -v -e ^$ -e ^# parent grep: parent: No such file or directory As we can see 'base' is the top most level of the profile and this is what does not get displayed. Idea here being that emerge -V displays the equiv of what the cascading profile really is. so base->hardened->x86 Infact my patch is wrong. base should be displayed before hardened/x86 not after. base/hardened/x86 Understand the idea? Not sure about this. It's easy enough to just follow the symlinks manually. There's also a big possibility of multiple "inheritance" before long. Does showing that hardened/x86 is indirectly a child of base actually add any extra information? What to do when the parent heirarchy is as complicated as hardened/x86 -> hardened -> linux/x86 -> linux -> base? > It's easy enough to just follow the symlinks manually. perhaps but the idea I'm after is to get the info displayed in bugzilla when a user reports a bug. I've seen the question raised before and nobody has ever answered clearly if *all* profiles inherit from base or not. Not that this could answer that.. > There's also a big possibility of multiple "inheritance" before long. Multiple "inheritance" would make the idea moot. But then when multiple "inheritance" happen the devs/us will need a quick way to understand how profiles are put together in order to resolve bugs and avoid chaos. Probably some a tree view. > Does showing that hardened/x86 is indirectly a child of base actually add any extra information? Yes. As it stands now devs (mainly for BSD?) are starting to shift misc virtuals/make.defaults/use.mask stuff around in the tree without prior notice assuming everybody uses said parent which is not always true. When this happens and default-linux is not apart of the profile hierarchy profiles such as hardened uclibc sometimes/often get broken in the process. So the end goal is to teach the devs and users about profile layout by visual representation. > What to do when the parent heirarchy is as complicated as hardened/x86 -> hardened -> linux/x86 -> linux -> base? Assuming you mean? base/linux/x86/hardened/x86 It seems like having ciaranm's graphviz view of the profiles published would be much better suited to this. As far as I can see, adding this would only show the users more information about their profile (which they generally either already know or don't care about). fine |
When we do an emerge -V/emerge info operation we get a display as such. Portage 2.0.51.21 (hardened/x86, gcc-3.3.5, glibc-2.3.5-r0, 2.4.31-pre2-hardened i686) The profilever() function reduces the string to hardened/x86 when the profile itself behaves like hardened/x86/base. A patch like the one below seems to fix this. I'm not 100% sure if this is the ideal fix or not but allows the display. Portage 2.0.51.21 (hardened/x86/base, gcc-3.3.5, glibc-2.3.5-r0, 2.4.31-pre2-hardened i686) Please review, improve as needed and commit. --- /dev/null 2005-05-15 20:13:05.000000000 -0400 +++ bin/emerge 2005-05-15 20:12:08.000000000 -0400 @@ -557,7 +557,14 @@ profilever = os.path.normpath("///"+os.readlink("/etc/make.profile")) basepath = os.path.normpath("///"+portage.settings["PORTDIR"]+"/profiles") if re.match(basepath,profilever): - profilever = profilever[len(basepath)+1:] + l = profilever + while os.path.exists(l): + if not os.path.exists(l+"/parent"): + break; + parent = string.join(portage.grabfile(l+"/parent")) + l += "/"+parent + + profilever = profilever[len(basepath)+1:]+"/"+os.path.basename(parent) else: profilever = "!"+profilever del basepath