Difference between pages "User:Ermo" and "Portage Profile Logic"

(Difference between pages)
m (Using dash as the default POSIX compliant /bin/sh in Funtoo Linux: less memory.)
 
 
Line 1: Line 1:
== Using dash as the default POSIX compliant /bin/sh in Funtoo Linux ==
+
== Gentoo Initialization ==
  
* Dash requires less memory and is faster than Bash (so all scripts referencing #!/bin/sh will run faster)
+
Gentoo profile initialization has been documented in [https://github.com/funtoo/portage-funtoo/commit/4c6826a0029c3c8f0aa92e70b4e50f2ffc58c7fa#diff-0 this GitHub commit], and describes how Gentoo's Portage finds and processes profiles. Funtoo Linux will be making some changes to this algorithm, but first things first -- document the existing functionality. Basically, Gentoo's Portage looks for profiles using this algorithm:
** In particular, Funtoo Linux systems will boot faster w/Dash than with Bash
+
** Configure scripts will be faster (every little thing counts)
+
** from 'man 3 system':
+
system() executes a command specified in command by calling /bin/sh -c command,
+
and returns after the command has been completed.
+
* Bash called via /bin/sh still supports Bash-isms, which is bad for scripts that are supposed to be portable (portability is a virtue in Funtoo Linux)
+
* Dash has fewer dependencies than Bash (sort of cool).
+
  
< ermo > So in that sense, using dash as /bin/sh aligns with one of the original core goals
+
# Does <tt>/etc/make.profile</tt> exist? If so, it defines the primary profile.
          for gentoo (and now funtoo) re. 'it would just allow for a leaner faster system'
+
# If not, does <tt>/etc/portage/make.profile</tt> exist? If so, it defines the primary profile.
< drobbins > ermo: right, it is a logical move for us
+
# Recursively process the <tt>parent</tt> file found in the primary profile to build a list of all cascading profiles
< drobbins > performance is not the main goal, but it is *a* goal
+
# if <tt>/etc/portage/profile</tt> exists, it is a user-defined profile - tack it to the end of our profile list so it can modify anything in the cascading profiles.
< drobbins > it is not something to be pursued at the expense of stability, reliability, etc.
+
  
'''References:'''
+
Here is a more detailed description of the steps:
* http://lists.debian.org/debian-devel/2009/06/msg00767.html
+
 
* http://www.debian.org/doc/debian-policy/ch-files.html#s10.4
+
# Look for a profile directory/symlink at <tt>/etc/make.profile</tt>, if one exists, use this as the main profile directory.
* https://wiki.ubuntu.com/DashAsBinSh
+
# If <tt>/etc/make.profile</tt> doesn't exist, use <tt>/etc/portage/make.profile</tt> as a back-up location if it exists.
 +
# 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 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.
 +
 
 +
[[Category:Portage]]

Revision as of 18:32, 21 January 2011

Gentoo Initialization

Gentoo profile initialization has been documented in this GitHub commit, and describes how Gentoo's Portage finds and processes profiles. Funtoo Linux will be making some changes to this algorithm, but first things first -- document the existing functionality. Basically, Gentoo's Portage looks for profiles using this algorithm:

  1. Does /etc/make.profile exist? If so, it defines the primary profile.
  2. If not, does /etc/portage/make.profile exist? If so, it defines the primary profile.
  3. Recursively process the parent file found in the primary profile to build a list of all cascading profiles
  4. if /etc/portage/profile exists, it is a user-defined profile - tack it to the end of our profile list so it can modify anything in the cascading profiles.

Here is a more detailed description of the steps:

  1. Look for a profile directory/symlink at /etc/make.profile, if one exists, use this as the main profile directory.
  2. If /etc/make.profile doesn't exist, use /etc/portage/make.profile as a back-up location if it exists.
  3. 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 LocationsManager._addProfile() recursive function will be called that will create a list of all cascading profiles. This works by looking for a parent 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 parent file is the highest-priority parent.

Once this list is created, the code checks to see if /etc/portage/profile 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.