Portage Profiles - Revision history

Drobbins at 18:32, 21 January 2011

2011-01-21T18:32:34Z

Drobbins at 17:17, 19 January 2011

2011-01-19T17:17:49Z

Drobbins at 01:21, 18 January 2011

2011-01-18T01:21:16Z

Drobbins at 18:15, 10 January 2011

2011-01-10T18:15:30Z

Drobbins: /* Proposed Funtoo Changes */

2011-01-10T18:12:39Z

‎Proposed Funtoo Changes

Tarsius: add to Category:Projects

2011-01-01T20:12:58Z

add to Category:Projects

Drobbins: mega-unification proposal

2010-12-30T02:41:28Z

mega-unification proposal

Drobbins: /* Proposed Funtoo Changes */

2010-12-28T16:21:02Z

‎Proposed Funtoo Changes

Ermo: /* Gentoo Initialization */ more than one parent.

2010-12-28T09:08:32Z

‎Gentoo Initialization: more than one parent.

Drobbins: /* Proposed Funtoo Changes */

2010-12-28T07:07:11Z

‎Proposed Funtoo Changes

← Older revision		Revision as of 18:32, 21 January 2011
Line 18:		Line 18:
	Once this list is created, the code checks to see if <tt>/etc/portage/profile</tt> directory exists. If it does, it is tacked at the end of the cascading profile list, meaning that it is evaluated last and this user-defined profile has the ability to modify any of the cascading profile settings. It provides an ideal hook point for a user-defined profile that can tweak anything the user wants to modify in the profile.		Once this list is created, the code checks to see if <tt>/etc/portage/profile</tt> directory exists. If it does, it is tacked at the end of the cascading profile list, meaning that it is evaluated last and this user-defined profile has the ability to modify any of the cascading profile settings. It provides an ideal hook point for a user-defined profile that can tweak anything the user wants to modify in the profile.

−	~~== Proposed Funtoo Changes ==~~
−
−	Suggested on the funtoo-dev mailing list, this proposal goes like this. There is a lot of duplication and unnecessary complexity in the Portage configuration directories. To address this, we can treat <tt>/etc/portage</tt> as the official Portage profile, and the user updates <tt>parents</tt> to specify parent profiles. This is how profiles are specified. <tt>/etc/make.conf</tt> can be replaced with <tt>make.defaults</tt> inside the <tt>/etc/portage</tt> directory, so that it follows the profile convention. Basically, this would merge <tt>/etc/portage/profile</tt> into <tt>/etc/portage</tt>, and also allow <tt>/etc/make.profile</tt> to be deprecated and replaced with <tt>/etc/portage/parent</tt>. <tt>make.conf</tt> could be treated as an alternative file naming for <tt>make.defaults</tt>, to allow <tt>/etc/portage/make.conf</tt> to be used.
−
−	The way this system would be used is that <tt>/etc/profile</tt> would be treated the official, canonical Portage profile, and <tt>/etc/portage/parents</tt> would be a file where a user would set their master profile(s). Absolute paths would be used to define profiles that are relative to <tt>PORTDIR/profiles</tt> (see change 6 above.) Since <tt>parent</tt> supports more than one profile, it would now be possible for users to set more than one parent profile, so they could set it to something that looks like this:
−
−	~~One area of the code that may need to be addressed (in addition to the obvious areas) are the updates functionality, which actually rewrites certain configuration files on package renames.~~
−
−	~~<pre>~~
−	~~/funtoo/1.0/linux/gnu/amd64~~
−	~~/funtoo/1.0/linux/flavor/server~~
−	~~</pre>~~
−
−	This additional functionality would allow the simplification of the funtoo-1.0 profile structure since the various "flavors" of systems would not need to be replicated within each architecture's profile. It would also clean up how profiles are set using Funtoo Linux. To me, this approach is much better and the <tt>profile.head</tt> and <tt>profile.tail</tt> names are much easier to understand than <tt>make.profile</tt> and <tt>profile</tt>.
−
−	~~This functionality could be implemented so that a fallback to the classic Gentoo functionality is preserved (for a time) to allow for migration to the new profile scheme.~~
−
−	~~== Funtoo Considerations ==~~
−
−	~~Here are some other things that might be worth considering:~~
−
−	# Overlay-aware profiles - should "/" be relative to $PORTDIR/profiles or should there be something more to allow repo-specific settings? Could be nice. Maybe support "foo:/bar/oni" to refer to the "/bar/oni" profile in the "foo" repository.
−	~~# since we are re-organizing things, move <tt>/etc/make.conf</tt> to <tt>/etc/portage/make.conf</tt> or <tt>/etc/portage/portage.conf</tt>.~~
−	~~# likewise, move <tt>/etc/make.globals</tt> to <tt>/etc/portage/make.globals</tt> or <tt>/etc/portage/portage.globals</tt>.~~
−
−	~~[[Category:Projects]]~~
	[[Category:Portage]]		[[Category:Portage]]
−	~~[[Category:Labs]]~~

← Older revision		Revision as of 17:17, 19 January 2011
Line 45:		Line 45:
	[[Category:Projects]]		[[Category:Projects]]
	[[Category:Portage]]		[[Category:Portage]]
		+	[[Category:Labs]]

← Older revision		Revision as of 01:21, 18 January 2011
Line 44:		Line 44:

	[[Category:Projects]]		[[Category:Projects]]
		+	[[Category:Portage]]

@@ Line 19: / Line 19: @@
 == Proposed Funtoo Changes ==
 The way this system would be used is that <tt>/etc/profile</tt> would be treated the official, canonical Portage profile, and <tt>/etc/portage/parents</tt> would be a file where a user would set their master profile(s). Absolute paths would be used to define profiles that are relative to <tt>PORTDIR/profiles</tt> (see change 6 above.)  Since <tt>parent</tt> supports more than one profile, it would now be possible for users to set more than one parent profile, so they could set it to something that looks like this:
 <pre>
@@ Line 30: / Line 34: @@
 This functionality could be implemented so that a fallback to the classic Gentoo functionality is preserved (for a time) to allow for migration to the new profile scheme.
 == Funtoo Considerations ==

@@ Line 20: / Line 20: @@
 == Proposed Funtoo Changes ==
-The current Portage profile functionality is a bit too complex, and is also missing some features that are needed for the funtoo-1.0 profile. The proposed changes here are designed to address these deficiencies, and are subject to change as the impact of these design changes are considered, and their elegance or ugliness is considered as well:
+The way this system would be used is that <tt>/etc/profile</tt> would be treated the official, canonical Portage profile, and <tt>/etc/portage/parents</tt> would be a file where a user would set their master profile(s). Absolute paths would be used to define profiles that are relative to <tt>PORTDIR/profiles</tt> (see change 6 above.)  Since <tt>parent</tt> supports more than one profile, it would now be possible for users to set more than one parent profile, so they could set it to something that looks like this:
-−
-# Deprecate <tt>/etc/make.profile</tt> symlink
-# Deprecate <tt>/etc/portage/make.profile</tt> symlink
-# Deprecate <tt>/etc/portage/profile</tt> directory
-# Add <tt>/etc/portage/profile.head</tt> as the master profile - intended to be a directory, not a symlink.
-# Add <tt>/etc/portage/profile.tail</tt> to replace <tt>/etc/portage/profile</tt> - functionally identical.
-# Add support for absolute paths in cascading profile <tt>parent</tt> files, to be interpreted as relative to the root of <tt>PORTDIR/profiles</tt>
-# Update <tt>eselect profile</tt> to deal with all this elegantly.
-−
-The way this system would be used is that <tt>/etc/portage/profile.head/parent</tt> would be a file where a user would set their master profile(s). Absolute paths would be used to define profiles that are relative to <tt>PORTDIR/profiles</tt> (see change 6 above.)  Since <tt>parent</tt> supports more than one profile, it would now be possible for users to set more than one parent profile, so they could set it to something that looks like this:
 <pre>

← Older revision		Revision as of 20:12, 1 January 2011
Line 52:		Line 52:
	# since we are re-organizing things, move <tt>/etc/make.conf</tt> to <tt>/etc/portage/make.conf</tt> or <tt>/etc/portage/portage.conf</tt>.		# since we are re-organizing things, move <tt>/etc/make.conf</tt> to <tt>/etc/portage/make.conf</tt> or <tt>/etc/portage/portage.conf</tt>.
	# likewise, move <tt>/etc/make.globals</tt> to <tt>/etc/portage/make.globals</tt> or <tt>/etc/portage/portage.globals</tt>.		# likewise, move <tt>/etc/make.globals</tt> to <tt>/etc/portage/make.globals</tt> or <tt>/etc/portage/portage.globals</tt>.
		+
		+	[[Category:Projects]]

← Older revision		Revision as of 02:41, 30 December 2010
Line 40:		Line 40:

	This functionality could be implemented so that a fallback to the classic Gentoo functionality is preserved (for a time) to allow for migration to the new profile scheme.		This functionality could be implemented so that a fallback to the classic Gentoo functionality is preserved (for a time) to allow for migration to the new profile scheme.
		+
		+	== Alternate Approach - Mega-Unification ==
		+
		+	Suggested on the funtoo-dev mailing list, this proposal goes like this. There is a lot of duplication and unnecessary complexity in the Portage configuration directories, so the original Funtoo proposal may not have gone far enough in refactoring the layout. Basically, we can treat <tt>/etc/portage</tt> as the official Portage profile, and the user updates <tt>parents</tt> to specify parent profiles. This is how profiles are specified. <tt>/etc/make.conf</tt> can be replaced with <tt>make.defaults</tt> inside the <tt>/etc/portage</tt> directory, so that it follows the profile convention. Basically, this would merge <tt>/etc/portage/profile</tt> into <tt>/etc/portage</tt>, and also allow <tt>/etc/make.profile</tt> to be deprecated and replaced with <tt>/etc/portage/parent</tt>.

	== Funtoo Considerations ==		== Funtoo Considerations ==

@@ Line 14: / Line 14: @@
 # If neither location exists, then a main profile directory doesn't exist and is undefined (None)
-Using the main profile directory/symlink found above, the <tt>LocationsManager._addProfile()</tt> recursive function will be called that will create a list of all cascading profiles. This works by looking for a <tt>parent</tt> file in the profile directory. If this file exists, then each line is treated as a ''relative path'' and used to modify the path to the current profile, pointing to a "parent" profile that this particular profile modifies. There can be one than more parent, one per line. ''The first line in the <tt>parent</tt> file is the highest-priority parent.''
+Using the main profile directory/symlink found above, the <tt>LocationsManager._addProfile()</tt> recursive function will be called that will create a list of all cascading profiles. This works by looking for a <tt>parent</tt> file in the profile directory. If this file exists, then each line is treated as a ''relative path'' and used to modify the path to the current profile, pointing to a "parent" profile that this particular profile modifies. There can be more than one parent, one per line. ''The first line in the <tt>parent</tt> file is the highest-priority parent.''
 Once this list is created, the code checks to see if <tt>/etc/portage/profile</tt> directory exists. If it does, it is tacked at the end of the cascading profile list, meaning that it is evaluated last and this user-defined profile has the ability to modify any of the cascading profile settings. It provides an ideal hook point for a user-defined profile that can tweak anything the user wants to modify in the profile.

@@ Line 37: / Line 37: @@
 </pre>
-This additional functionality would allow the simplification of the funtoo-1.0 profile structure since the various "flavors" of systems would not need to be replicated within each architecture's profile. It would also clean up how profiles are set using Funtoo Linux. This functionality could be implemented so that a fallback to the classic Gentoo functionality is preserved (for a time) to allow for migration to the new profile scheme.
+This additional functionality would allow the simplification of the funtoo-1.0 profile structure since the various "flavors" of systems would not need to be replicated within each architecture's profile. It would also clean up how profiles are set using Funtoo Linux. To me, this approach is much better and the <tt>profile.head</tt> and <tt>profile.tail</tt> names are much easier to understand than <tt>make.profile</tt> and <tt>profile</tt>.
 == Funtoo Considerations ==