Difference between pages "Bash by Example, Part 3" and "Funtoo Profiles"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
m
 
Line 1: Line 1:
{{Article
{{#widget:AddThis}}
|Subtitle=Exploring the ebuild system
== What is a profile? ==
|Summary=Few people know that the original version of Portage was an evolution of a simple script that I wrote for a bash tutorial. Here's the article that contains the first version of ebuild! Learn how to script by creating a minimal build script.
|Author=Drobbins
|Previous in Series=Bash by Example, Part 2
}}
=== Enter the ebuild system ===
I've really been looking forward to this third and final ''Bash by example'' article, because now that we've already covered bash programming fundamentals in [[Bash by example, Part1|Part 1]] and [[Bash by example, Part 2|Part 2]], we can focus on more advanced topics, like bash application development and program design. For this article, I will give you a good dose of practical, real-world bash development experience by presenting a project that I've spent many hours coding and refining: the Gentoo Linux ebuild system.


As the creator of Gentoo Linux and the guy behind Funtoo Linux, one of my primary responsibilities is to make sure that all of the operating system packages (similar to RPM packages) are created properly and work together. As you probably know, a standard Linux system is not composed of a single unified source tree (like BSD), but is actually made up of about 25+ (As of 2015, over 100! -Ed) core packages that work together. Some of the packages include:
In Gentoo and Funtoo Linux, profiles are used to define base system settings, and have historically had a lot of untapped potential. In Funtoo Linux, I wanted to take advantage of some of this potential to allow Funtoo Linux users to easily tailor their system for various types of roles. Enter the new Funtoo profile system.


{{TableStart}}
== What It Is ==
<tr><td class="active">Package</td><td class="active">Description</td></tr>
<tr><td>linux</td><td>The actual kernel</td></tr>
<tr><td>util-linux</td><td>A collection of miscellaneous Linux-related programs</td></tr>
<tr><td>e2fsprogs</td><td>A collection of ext2 filesystem-related utilities</td></tr>
<tr><td>glibc</td><td>The GNU C library</td></tr>
{{TableEnd}}


{{Note|Gentoo fans: the original text above used to say "I'm the chief architect of Gentoo Linux, a next-generation Linux OS currently in beta. One of my primary responsibilities is to make sure that all of the binary packages (similar to RPM packages) are created properly and work together." This is noteworthy due to the fact that the initial focus of Gentoo was to provide working binary packages.}}
Historically, users have had to add a ton of settings to <code>/etc/[[make.conf]]</code> to customize their Gentoo or Funtoo Linux system, which made setup of the operating system more difficult than it should be.


Each package is in its own tarball and is maintained by separate independent developers, or teams of developers. To create a distribution, each package has to be separately downloaded, compiled, and packaged. Every time a package must be fixed, upgraded, or improved, the compilation and packaging steps must be repeated (and this gets old really fast). To help eliminate the repetitive steps involved in creating and updating packages, I created the ebuild system, written almost entirely in bash. To enhance your bash knowledge, I'll show you how I implemented the unpack and compile portions of the ebuild system, step by step. As I explain each step, I'll also discuss why certain design decisions were made. By the end of this article, not only will you have an excellent grasp of larger-scale bash programming projects, but you'll also have implemented a good portion of a complete auto-build system.
In Gentoo Linux, it is possible to only define one ''system profile''. Think of a system profile as the default settings that Portage uses for building everything on your system.


=== Why bash? ===
In Funtoo Linux, multiple profiles can be enabled at the same time. These include:
Bash is an essential component of the Gentoo Linux ebuild system. It was chosen as ebuild's primary language for a number of reasons. First, it has an uncomplicated and familiar syntax that is especially well suited for calling external programs. An auto-build system is "glue code" that automates the calling of external programs, and bash is very well suited to this type of application. Second, Bash's support for functions allowed the ebuild system to have modular, easy-to-understand code. Third, the ebuild system takes advantage of bash's support for environment variables, allowing package maintainers and developers to configure it easily, on-the-fly.


=== Build process review ===
* '''arch''' - one arch profile is enabled, at build time, and is not changed. This defines CPU architecture-specific settings.
Before we look at the ebuild system, let's review what's involved in getting a package compiled and installed. For our example, we will look at the "sed" package, a standard GNU text stream editing utility that is part of all Linux distributions. First, download the source tarball ('''sed-3.02.tar.gz''') (see [[#Resources|Resources]]). We will store this archive in '''/usr/src/distfiles''', a directory we will refer to using the environment variable <span style="color:green">$DISTDIR</span>. <span style="color:green">$DISTDIR</span> is the directory where all of our original source tarballs live; it's a big vault of source code.
* '''build''' - one build profile is enabled, at build time, and is generally not changed. It defines the type of build, such as 'current' or 'stable', and associated settings.
* '''flavor''' - one flavor is enabled per system, and can be changed by the user. This defines the general use of the system, such as 'minimal', 'core', 'workstation' or 'desktop'
* '''mix-in''' - zero or more mix-ins can be enabled that enable settings specific to a particular subset of features, such as 'gnome', 'kde', 'media', 'mate', 'X', 'hardened'


Our next step is to create a temporary directory called '''work''', which houses the uncompressed sources. We'll refer to this directory later using the <span style="color:green">$WORKDIR</span> environment variable. To do this, change to a directory where we have write permission and type the following:
{{Fancynote|1=
<source lang="bash">
See [[Flavors and Mix-ins]] for a complete list of all flavors and mix-ins available in Funtoo Linux, along with descriptions of what each one does.}}
$ mkdir work
$ cd work
$ tar xzf /usr/src/distfiles/sed-3.02.tar.gz
</source>
The tarball is then decompressed, creating a directory called '''sed-3.02''' that contains all of the sources. We'll refer to the '''sed-3.02''' directory later using the environment variable <span style="color:green">$SRCDIR</span>. To compile the program, type the following:
<source lang="bash">
$ cd sed-3.02
$ ./configure --prefix=/usr
(autoconf generates appropriate makefiles, this can take a while)


$ make
=== Origins and Benefits ===


(the package is compiled from sources, also takes a bit of time)
This new system is really a completion of the original cascading profile design that was designed by Daniel Robbins and implemented by Seemant Kulleen as part of Portage. Funtoo Profiles designed to leverage the existing cascading profile system and provide something much more useable and maintainable for users and developers alike. Here are some of its benefits:
</source>
We're going to skip the "make install" step, since we are just covering the unpack and compile steps in this article. If we wanted to write a bash script to perform all these steps for us, it could look something like this:
<source lang="bash">
#!/usr/bin/env bash


if [ -d work ]
* Fewer settings in <code>/etc/make.conf</code>. <code>CHOST</code> and <code>ARCH</code> no longer set in <code>/etc/make.conf</code>.
then
* Separation of concerns -- arch, build, and flavor-related settings are organized together.
# remove old work directory if it exists
* User flexibility - any number of mix-ins can be enabled to tweak masks or USE settings as needed.
      rm -rf work
fi
mkdir work
cd work
tar xzf /usr/src/distfiles/sed-3.02.tar.gz
cd sed-3.02
./configure --prefix=/usr
make
</source>


=== Generalizing the code ===
{{fancynote|See [[Custom Profiles]] for information on how to extend the profile system.}}
Although this autocompile script works, it's not very flexible. Basically, the bash script just contains the listing of all the commands that were typed at the command line. While this solution works, it would be nice to make a generic script that can be configured quickly to unpack and compile any package just by changing a few lines. That way, it's much less work for the package maintainer to add new packages to the distribution. Let's take a first stab at doing this by using lots of different environment variables, making our build script more generic:
<source lang="bash">
#!/usr/bin/env bash


# P is the package name
== Switch to the Funtoo 1.0 Profile ==


P=sed-3.02
=== Using eselect ===
The preferred method of adding and removing profiles is to use [[eselect|eselect profile]]. This will ensure that profiles are added correctly and in the proper order. The order is imperative for things to work right.


# A is the archive name
Type the following to view a list of available options for '''eselect profile''':
<console>
###i## eselect profile help
</console>


A=${P}.tar.gz


export ORIGDIR=`pwd`
For a start, let's see what the default configuration has to offer. Get an overview using the '''list''' command:
export WORKDIR=${ORIGDIR}/work
<console>
export SRCDIR=${WORKDIR}/${P}
###i## eselect profile list
##b####g##Currently available arch profiles:
  ##b##[1]  funtoo/1.0/linux-gnu/arch/x86-64bit##!b## *
  ##b##[2]##!b##  funtoo/1.0/linux-gnu/arch/pure64
##b####g##Currently available build profiles:
  ##b##[3]##!b##  funtoo/1.0/linux-gnu/build/stable
  ##b##[4]  funtoo/1.0/linux-gnu/build/current##!b## *
  ##b##[5]##!b##  funtoo/1.0/linux-gnu/build/experimental
##b####g##Currently available flavor profiles:
  ##b##[6]##!b##  funtoo/1.0/linux-gnu/flavor/minimal
  ##b##[7]  funtoo/1.0/linux-gnu/flavor/core##!b## *
  ##b##[8]##!b##  funtoo/1.0/linux-gnu/flavor/desktop
  ##b##[9]##!b##  funtoo/1.0/linux-gnu/flavor/workstation
  ##b##[10]##!b##  funtoo/1.0/linux-gnu/flavor/hardened
##b####g##Currently available mix-ins profiles:
  ##b##[11]##!b##  funtoo/1.0/linux-gnu/mix-ins/audio
  ##b##[12]##!b##  funtoo/1.0/linux-gnu/mix-ins/cinnamon
  ##b##[13]##!b##  funtoo/1.0/linux-gnu/mix-ins/console-extras
  ##b##[14]##!b##  funtoo/1.0/linux-gnu/mix-ins/dvd
  ##b##[15]##!b##  funtoo/1.0/linux-gnu/mix-ins/gnome
  ##b##[16]##!b##  funtoo/1.0/linux-gnu/mix-ins/kde
  ##b##[17]##!b##  funtoo/1.0/linux-gnu/mix-ins/mate
  ##b##[18]##!b##  funtoo/1.0/linux-gnu/mix-ins/media
  ##b##[19]##!b##  funtoo/1.0/linux-gnu/mix-ins/print
  ##b##[20]##!b##  funtoo/1.0/linux-gnu/mix-ins/python3-only
  ##b##[21]##!b##  funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
  ##b##[22]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-db
  ##b##[23]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-mail
  ##b##[24]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-web
  ##b##[25]##!b##  funtoo/1.0/linux-gnu/mix-ins/X
  ##b##[26]##!b##  funtoo/1.0/linux-gnu/mix-ins/xfce
  ##b##[27]##!b##  funtoo/1.0/linux-gnu/mix-ins/vmware-guest
  ##b##[28]##!b##  funtoo/1.0/linux-gnu/mix-ins/hardened
</console>


if [ -z "$DISTDIR" ]
As in several other Funtoo utilities, a star ('''*''') on the right indicates an active item (your case may differ from the example above).
then
In most cases you will want to set your "flavor" first. Remember that you can only set ''one'' flavor at time.
# set DISTDIR to /usr/src/distfiles if not already set
        DISTDIR=/usr/src/distfiles
fi
export DISTDIR


if [ -d ${WORKDIR} ]
To choose your favorite flavor use the '''set-flavor''' command including your selection. In this example, we will set the '''desktop''' flavor:
then   
{{Fancynote| You ''must'' use numbers to reference to the profiles you want.}}
# remove old work directory if it exists
<console>###i## eselect profile set-flavor 8</console>
        rm -rf ${WORKDIR}
View the result:
fi
<console>###i## eselect profile list
##b####g##Currently available arch profiles:
  ##b##[1]  funtoo/1.0/linux-gnu/arch/x86-64bit##!b## *
  ##b##[2]##!b##  funtoo/1.0/linux-gnu/arch/pure64
##b####g##Currently available build profiles:
  ##b##[3]##!b##  funtoo/1.0/linux-gnu/build/stable
  ##b##[4]  funtoo/1.0/linux-gnu/build/current##!b## *
  ##b##[5]##!b##  funtoo/1.0/linux-gnu/build/experimental
##b####g##Currently available flavor profiles:
  ##b##[6]##!b##  funtoo/1.0/linux-gnu/flavor/minimal
  ##b##[7]##!b##  funtoo/1.0/linux-gnu/flavor/core
  ##b##[8]  funtoo/1.0/linux-gnu/flavor/desktop##!b## *
  ##b##[9]##!b##  funtoo/1.0/linux-gnu/flavor/workstation
  ##b##[10]##!b##  funtoo/1.0/linux-gnu/flavor/hardened
##b####g##Currently available mix-ins profiles:
  ##b##[11]  funtoo/1.0/linux-gnu/mix-ins/audio (auto)
  ##b##[12]##!b##  funtoo/1.0/linux-gnu/mix-ins/cinnamon
  ##b##[13]  funtoo/1.0/linux-gnu/mix-ins/console-extras (auto)
  ##b##[14]  funtoo/1.0/linux-gnu/mix-ins/dvd (auto)
  ##b##[15]##!b##  funtoo/1.0/linux-gnu/mix-ins/gnome
  ##b##[16]##!b##  funtoo/1.0/linux-gnu/mix-ins/kde
  ##b##[17]##!b##  funtoo/1.0/linux-gnu/mix-ins/mate
  ##b##[18]  funtoo/1.0/linux-gnu/mix-ins/media (auto)
  ##b##[19]  funtoo/1.0/linux-gnu/mix-ins/print (auto)
  ##b##[20]##!b##  funtoo/1.0/linux-gnu/mix-ins/python3-only
  ##b##[21]##!b##  funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
  ##b##[22]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-db
  ##b##[23]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-mail
  ##b##[24]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-web
  ##b##[25] funtoo/1.0/linux-gnu/mix-ins/X (auto)
  ##b##[26]##!b##  funtoo/1.0/linux-gnu/mix-ins/xfce
  ##b##[27]##!b##  funtoo/1.0/linux-gnu/mix-ins/vmware-guest
  ##b##[28]##!b##  funtoo/1.0/linux-gnu/mix-ins/hardened
</console>
As you see by the '''(auto)''' entries, the '''desktop''' flavor already pre-set some mix-ins for you.


mkdir ${WORKDIR}
Now, let's head over and add some mix-ins. To add, say, the mix-ins '''gnome''' and '''kde''' we'd have to enter:
cd ${WORKDIR}
tar xzf ${DISTDIR}/${A}
cd ${SRCDIR}
./configure --prefix=/usr
make
</source>
We've added a lot of environment variables to the code, but it still does basically the same thing. However, now, to compile any standard GNU autoconf-based source tarball, we can simply copy this file to a new file (with an appropriate name to reflect the name of the new package it compiles), and then change the values of <span style"color:green:>$A</span> and <span style"color:green:>$P</span> to new values. All other environment variables automatically adjust to the correct settings, and the script works as expected. While this is handy, there's a further improvement that can be made to the code. This particular code is much longer than the original "transcript" script that we created. Since one of the goals for any programming project should be the reduction of complexity for the user, it would be nice to dramatically shrink the code, or at least organize it better. We can do this by performing a neat trick -- we'll split the code into two separate files. Save this file as '''sed-3.02.ebuild''':
<source lang="bash">
#the sed ebuild file -- very simple!
P=sed-3.02
A=${P}.tar.gz
</source>
Our first file is trivial, and contains only those environment variables that must be configured on a per-package basis. Here's the second file, which contains the brains of the operation. Save this one as "ebuild" and make it executable:
<source lang="bash">
#!/usr/bin/env bash


<console>
###i## eselect profile add 15
###i## eselect profile add 16
</console>


if [ $# -ne 1 ]
Or, in a one-shot:
then
        echo "one argument expected."
        exit 1
fi


if [ -e "$1" ]
<console>
then
###i## eselect profile add 15 16
        source $1
</console>
else
        echo "ebuild file $1 not found."
        exit 1
fi


export ORIGDIR=`pwd`
If we want to remove a mix-in, for example '''gnome''', simply enter:
export WORKDIR=${ORIGDIR}/work
export SRCDIR=${WORKDIR}/${P}


if [ -z "$DISTDIR" ]
<console>
then
###i## eselect profile remove 15
        # set DISTDIR to /usr/src/distfiles if not already set
</console>
        DISTDIR=/usr/src/distfiles
fi
export DISTDIR


if [ -d ${WORKDIR} ]
Verification:
then   
        # remove old work directory if it exists
        rm -rf ${WORKDIR}
fi


mkdir ${WORKDIR}
<console>###i## eselect profile list
cd ${WORKDIR}
##b####g##Currently available arch profiles:
tar xzf ${DISTDIR}/${A}
  ##b##[1]  funtoo/1.0/linux-gnu/arch/x86-64bit##!b## *
cd ${SRCDIR}
  ##b##[2]##!b##  funtoo/1.0/linux-gnu/arch/pure64
./configure --prefix=/usr
##b####g##Currently available build profiles:
make
  ##b##[3]##!b##  funtoo/1.0/linux-gnu/build/stable
</source>
  ##b##[4]  funtoo/1.0/linux-gnu/build/current##!b## *
Now that we've split our build system into two files, I bet you're wondering how it works. Basically, to compile sed, type:
  ##b##[5]##!b##  funtoo/1.0/linux-gnu/build/experimental
<source lang="bash">
##b####g##Currently available flavor profiles:
$ ./ebuild sed-3.02.ebuild
  ##b##[6]##!b##  funtoo/1.0/linux-gnu/flavor/minimal
</source>
  ##b##[7]##!b##  funtoo/1.0/linux-gnu/flavor/core
When "ebuild" executes, it first tries to "source" variable <span style="color:green">$1</span>. What does this mean? From my previous article, recall that <span style="color:green">$1</span> is the first command line argument -- in this case, '''sed-3.02.ebuild'''. In bash, the "source" command reads in bash statements from a file, and executes them as if they appeared immediately in the file the "source" command is in. So, "source ${1}" causes the "ebuild" script to execute the commands in '''sed-3.02.ebuild''', which cause <span style="color:green">$P</span> and <span style="color:green">$A</span> to be defined. This design change is really handy, because if we want to compile another program instead of sed, we can simply create a new '''.ebuild''' file and pass it as an argument to our "ebuild" script. That way, the '''.ebuild''' files end up being really simple, while the complicated brains of the ebuild system get stored in one place -- our "ebuild" script. This way, we can upgrade or enhance the ebuild system simply by editing the "ebuild" script, keeping the implementation details outside of the ebuild files. Here's a sample ebuild file for <span style="color:green">gzip</span>:
  ##b##[8]  funtoo/1.0/linux-gnu/flavor/desktop##!b## *
<source lang="bash">
  ##b##[9]##!b##  funtoo/1.0/linux-gnu/flavor/workstation
#another really simple ebuild script!
  ##b##[10]##!b##  funtoo/1.0/linux-gnu/flavor/hardened
P=gzip-1.2.4a
##b####g##Currently available mix-ins profiles:
A=${P}.tar.gz
  ##b##[11]  funtoo/1.0/linux-gnu/mix-ins/audio (auto)
</source>
  ##b##[12]##!b##  funtoo/1.0/linux-gnu/mix-ins/cinnamon
  ##b##[13]  funtoo/1.0/linux-gnu/mix-ins/console-extras (auto)
  ##b##[14]  funtoo/1.0/linux-gnu/mix-ins/dvd (auto)
  ##b##[15]##!b##  funtoo/1.0/linux-gnu/mix-ins/gnome
  ##b##[16]  funtoo/1.0/linux-gnu/mix-ins/kde *
  ##b##[17]##!b##  funtoo/1.0/linux-gnu/mix-ins/mate
  ##b##[18]  funtoo/1.0/linux-gnu/mix-ins/media (auto)
  ##b##[19]  funtoo/1.0/linux-gnu/mix-ins/print (auto)
  ##b##[20]##!b##  funtoo/1.0/linux-gnu/mix-ins/python3-only
  ##b##[21]##!b##  funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
  ##b##[22]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-db
  ##b##[23]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-mail
  ##b##[24]##!b##  funtoo/1.0/linux-gnu/mix-ins/server-web
  ##b##[25]  funtoo/1.0/linux-gnu/mix-ins/X (auto)
  ##b##[26]##!b##  funtoo/1.0/linux-gnu/mix-ins/xfce
  ##b##[27]##!b##  funtoo/1.0/linux-gnu/mix-ins/vmware-guest
  ##b##[28]##!b##  funtoo/1.0/linux-gnu/mix-ins/hardened
</console>


=== Adding functionality ===
OK, we're making some progress. But, there is some additional functionality I'd like to add. I'd like the ebuild script to accept a second command-line argument, which will be <span style="color:green">compile</span>, <span style="color:green">unpack</span>, or <span style="color:green">all</span>. This second command-line argument tells the ebuild script which particular step of the build process to perform. That way, I can tell ebuild to unpack the archive, but not compile it (just in case I need to inspect the source archive before compilation begins). To do this, I'll add a case statement that will test variable <span style="color:green">$2</span>, and do different things based on its value. Here's what the code looks like now:
<source lang="bash">
#!/usr/bin/env bash


if [ $# -ne 2 ]
No magic here, whatever you add gets put into the <code>/etc/portage/make.profile/parent</code> file by portage.
then
        echo "Please specify two args - .ebuild file and unpack, compile or all"
        exit 1
fi


In our case, this file contains:
<console>
###i## cat /etc/portage/make.profile/parent
gentoo:funtoo/1.0/linux-gnu/arch/x86-64bit
gentoo:funtoo/1.0/linux-gnu/build/current
gentoo:funtoo/1.0/linux-gnu/flavor/desktop
gentoo:funtoo/1.0/linux-gnu/mix-ins/kde
</console>
{{fancywarning|Please, do not add anything manually into <code>parent</code> file. This may result in profile breakage.}}


if [ -z "$DISTDIR" ]
== For Developers ==
then
# set DISTDIR to /usr/src/distfiles if not already set
        DISTDIR=/usr/src/distfiles
fi
export DISTDIR


ebuild_unpack() {
=== Define the profile sub-sets you will use ===
        #make sure we're in the right directory
        cd ${ORIGDIR}
       
        if [ -d ${WORKDIR} ]
        then   
                rm -rf ${WORKDIR}
        fi


        mkdir ${WORKDIR}
So far in Funtoo we have used the exact same profiles as Gentoo thus Funtoo/2008.0 was strictly the same thing as Gentoo/2008.0 or the barely the same 10.0. This (monolithic) profile was set though a symbolic link named <code>/etc/make.profile</code> pointing on a complex directory architecture located somewhere under <code>/usr/portage/profiles</code>. This is no longer valid with the Funtoo 1.0 profiles as they are split in several smaller bricks which are then glued together via the  <code>/etc/portage/make.profile/parent</code> file (You do not need to include everything, just use the "bricks" you need). Those bricks belongs to several categories:
        cd ${WORKDIR}
        if [ ! -e ${DISTDIR}/${A} ]
        then
            echo "${DISTDIR}/${A} does not exist. Please download first."
            exit 1
        fi   
        tar xzf ${DISTDIR}/${A}
        echo "Unpacked ${DISTDIR}/${A}."
        #source is now correctly unpacked
}


# MANDATORY -- An "arch" profile which defines settings for a particular architecture. You'll want to set this to whatever arch your system is and leave it alone. '''Setting it to a different arch than your system could severely break it.'''
# MANDATORY -- A "build" profile which should match the tree you wish to use. '''Stable''', '''Current''' (~arch), or '''Experimental''' (use it if you are brave enough and find '''current''' too stable).
# MANDATORY -- A "flavor" profile (what was previously known as ''profiles'' is still known as such in Gentoo) which describes the kind of system you want:
#* minimal - Be warned, minimal is exactly what it says, the minimal profile stuff you need for a usable system, nothing else. This is really for people who know what they're doing.
#* core - This is the core profile. This is for stuff that affects both desktops and servers.
#* desktop - Exactly what it says. If you're using a desktop, you should set this as your flavor.
#* server - If you're running a server, you should set this as your flavor.
# OPTIONAL -- One or more "mix-ins" profiles which describe optional add-ons. 'mix-ins' are the heart of the Funtoo 1.0 profiles. Unlike the monolithic profiles which sets a massive amount of use flags and options for you, we've split them into logical add-on profiles. For instance if you want support for gnome, you would add the gnome mix-in to your current profiles. That mix-in sets all the proper use flags and such for gnome. Same with others. Want dvd support? Add that one in. Using a rhel5 kernel which requires special versions of packages such as udev? There's a mix-in for that too. Run a mail server? web server? There's mix-ins for those also. Expect this category to grow in the future as new mix-ins are created.


ebuild_compile() {
The contents of <code>/etc/portage/make.profile/parent</code> for a basic setup might look like this:
       
        #make sure we're in the right directory
        cd ${SRCDIR}
        if [ ! -d "${SRCDIR}" ]
        then
                echo "${SRCDIR} does not exist -- please unpack first."
                exit 1
        fi
        ./configure --prefix=/usr
        make   
}


export ORIGDIR=`pwd`
{{file|name=/etc/portage/make.profile/parent|body=
export WORKDIR=${ORIGDIR}/work
gentoo:funtoo/1.0/linux-gnu/arch/x86-64bit
gentoo:funtoo/1.0/linux-gnu/build/current
gentoo:funtoo/1.0/linux-gnu/flavor/core
}}


if [ -e "$1" ]
A more rounded setup for a desktop might look like this:
then
        source $1
else
        echo "Ebuild file $1 not found."
        exit 1
fi


export SRCDIR=${WORKDIR}/${P}
{{file|name=/etc/portage/make.profile/parent|body=
 
gentoo:funtoo/1.0/linux-gnu/arch/x86-64bit
case "${2}" in
gentoo:funtoo/1.0/linux-gnu/build/current
        unpack)
gentoo:funtoo/1.0/linux-gnu/flavor/desktop
                ebuild_unpack
gentoo:funtoo/1.0/linux-gnu/mix-ins/dvd
                ;;
gentoo:funtoo/1.0/linux-gnu/mix-ins/media
        compile)
}}
                ebuild_compile
                ;;
        all)
                ebuild_unpack
                ebuild_compile
                ;;
        *)
                echo "Please specify unpack, compile or all as the second arg"
                exit 1
                ;;
esac
</source>
We've made a lot of changes, so let's review them. First, we placed the compile and unpack steps in their own functions, and called <span style="color:green:>ebuild_compile()</span> and <span style="color:green">ebuild_unpack()</span>, respectively. This is a good move, since the code is getting more complicated, and the new functions provide some modularity, which helps to keep things organized. On the first line in each function, I explicitly <span style="color:green">cd</span> into the directory I want to be in because, as our code is becoming more modular rather than linear, it's more likely that we might slip up and execute a function in the wrong current working directory. The <span style="color:green">cd</span> commands explicitly put us in the right place, and prevent us from making a mistake later -- an important step -- especially if you will be deleting files inside the functions.
 
Also, I added a useful check to the beginning of the <span style="color:green">ebuild_compile()</span> function. Now, it checks to make sure the <span style="color:green">$SRCDIR</span> exists, and, if not, it prints an error message telling the user to unpack the archive first, and then exits. If you like, you can change this behavior so that if <span style="color:green">$SRCDIR</span> doesn't exist, our ebuild script will unpack the source archive automatically. You can do this by replacing <span style="color:green">ebuild_compile()</span> with the following code:
<source lang="bash">
ebuild_compile() {
        #make sure we're in the right directory
        if [ ! -d "${SRCDIR}" ]
        then
                ebuild_unpack
        fi
        cd ${SRCDIR}
        ./configure --prefix=/usr
        make   
}
</source>
One of the most obvious changes in our second version of the ebuild script is the new case statement at the end of the code. This case statement simply checks the second command-line argument, and performs the correct action, depending on its value. If we now type:
<source lang="bash">
$ ebuild sed-3.02.ebuild
</source>
We'll actually get an error message. ebuild now wants to be told what to do, as follows:
<source lang="bash">
$ ebuild sed-3.02.ebuild unpack
</source>
or:
<source lang="bash">
$ ebuild sed-3.02.ebuild compile
</source>
or:
<source lang="bash">
$ ebuild sed-3.02.ebuild all
</source>
 
{{fancyimportant|If you provide a second command-line argument, other than those listed above, you get an error message (the * clause), and the program exits.}}
 
=== Modularizing the code ===
Now that the code is quite advanced and functional, you may be tempted to create several more ebuild scripts to unpack and compile your favorite programs. If you do, sooner or later you'll come across some sources that do not use autoconf (<span style="color:green">./configure</span>) or possibly others that have non-standard compilation processes. We need to make some more changes to the ebuild system to accommodate these programs. But before we do, it is a good idea to think a bit about how to accomplish this.
 
One of the great things about hard-coding <span style="color:green">./configure --prefix=/usr; make</span> into our compile stage is that, most of the time, it works. But, we must also have the ebuild system accommodate sources that do not use autoconf or normal Makefiles. To solve this problem, I propose that our ebuild script should, by default, do the following:
 
# If there is a configure script in <span style="color:green">${SRCDIR}</span>, execute it as follows: <span style="color:green">./configure --prefix=/usr</span>. Otherwise, skip this step.
# Execute the following command: make
 
Since ebuild only runs configure if it actually exists, we can now automatically accommodate those programs that don't use autoconf and have standard makefiles. But what if a simple "make" doesn't do the trick for some sources? We need a way to override our reasonable defaults with some specific code to handle these situations. To do this, we'll transform our <span style="color:green">ebuild_compile()</span> function into two functions. The first function, which can be looked at as a "parent" function, will still be called <span style="color:green">ebuild_compile()</span>. However, we'll have a new function, called <span style="color:green">user_compile()</span>, which contains only our reasonable default actions:
<source lang="bash">
user_compile() {
        #we're already in ${SRCDIR}
        if [ -e configure ]
        then
                #run configure script if it exists
                ./configure --prefix=/usr
        fi
        #run make
        make
}             
 
ebuild_compile() {
        if [ ! -d "${SRCDIR}" ]
        then
                echo "${SRCDIR} does not exist -- please unpack first."
                exit 1
        fi
        #make sure we're in the right directory
        cd ${SRCDIR}
        user_compile
}
</source>
It may not seem obvious why I'm doing this right now, but bear with me. While the code works almost identically to our previous version of ebuild, we can now do something that we couldn't do before -- we can override <span style="color:green">user_compile()</span> in '''sed-3.02.ebuild'''. So, if the default <span style="color:green:>user_compile()</span> function doesn't meet our needs, we can define a new one in our '''.ebuild''' file that contains the commands required to compile the package. For example, here's an ebuild file for <span style="color:green">e2fsprogs-1.18</span>, which requires a slightly different <span style="color:green">./configure</span> line:
<source lang="bash">
#this ebuild file overrides the default user_compile()
P=e2fsprogs-1.18
A=${P}.tar.gz
user_compile() {
      ./configure --enable-elf-shlibs
      make
}
</source>
Now, <span style="color:green">e2fsprogs</span> will be compiled exactly the way we want it to be. But, for most packages, we can omit any custom <span style="color:green">user_compile()</span> function in the '''.ebuild''' file, and the default user_compile() function is used instead.
 
How exactly does the ebuild script know which user_compile() function to use? This is actually quite simple. In the ebuild script, the default <span style="color:green">user_compile()</span> function is defined before the '''e2fsprogs-1.18.ebuild''' file is sourced. If there is a <span style="color:green">user_compile()</span> in '''e2fsprogs-1.18.ebuild''', it overwrites the default version defined previously. If not, the default <span style="color:green">user_compile()</span> function is used.
 
This is great stuff; we've added a lot of flexibility without requiring any complex code if it's not needed. We won't cover it here, but you could also make similar modifications to <span style="color:green">ebuild_unpack()</span> so that users can override the default unpacking process. This could come in handy if any patching has to be done, or if the files are contained in multiple archives. It is also a good idea to modify our unpacking code so that it recognizes bzip2-compressed tarballs by default.
 
=== Configuration files ===
We've covered a lot of sneaky bash techniques so far, and now it's time to cover one more. Often, it's handy for a program to have a global configuration file that resides in '''/etc'''. Fortunately, this is easy to do using bash. Simply create the following file and save it as '''/etc/ebuild.conf''':
<source lang="bash">
# /etc/ebuild.conf: set system-wide ebuild options in this file
 
# MAKEOPTS are options passed to make
MAKEOPTS="-j2"
</source>
In this example, I've included just one configuration option, but you could include many more. One of the beautiful things about bash is that this file can be parsed by simply sourcing it. This is a design trick that works with most interpreted languages. After '''/etc/ebuild.conf''' is sourced, <span style="color:green">$MAKEOPTS</span> is defined inside our ebuild script. We'll use it to allow the user to pass options to make. Normally, this option would be used to allow the user to tell ebuild to do a parallel make. This is explained below.
 
{{fancynote|'''What is a parallel make?''' <nowiki>To speed compilation on multiprocessor systems, make supports compiling a program in parallel. This means that instead of compiling just one source file at a time, make compiles a user-specified number of source files simultaneously (so those extra processors in a multiprocessor system are used). Parallel makes are enabled by passing the -j # option to make, as follows: make -j4 MAKE="make -j4". This code instructs make to compile four programs simultaneously. The MAKE="make -j4" argument tells make to pass the -j4 option to any child make processes it launches.</nowiki>}}
 
Here's the final version of our ebuild program:
<source lang="bash">
#!/usr/bin/env bash
 
if [ $# -ne 2 ]
then
        echo "Please specify ebuild file and unpack, compile or all"
        exit 1
fi
 
source /etc/ebuild.conf
 
if [ -z "$DISTDIR" ]
then
        # set DISTDIR to /usr/src/distfiles if not already set
        DISTDIR=/usr/src/distfiles
fi
export DISTDIR
 
ebuild_unpack() {
        #make sure we're in the right directory
        cd ${ORIGDIR}
       
        if [ -d ${WORKDIR} ]
        then   
                rm -rf ${WORKDIR}
        fi
 
        mkdir ${WORKDIR}
        cd ${WORKDIR}
        if [ ! -e ${DISTDIR}/${A} ]
        then
                echo "${DISTDIR}/${A} does not exist.  Please download first."
                exit 1
        fi
        tar xzf ${DISTDIR}/${A}
        echo "Unpacked ${DISTDIR}/${A}."
        #source is now correctly unpacked
}
 
user_compile() {
        #we're already in ${SRCDIR}
        if [ -e configure ]
        then
                #run configure script if it exists
                ./configure --prefix=/usr
        fi
        #run make
        make $MAKEOPTS MAKE="make $MAKEOPTS" 
}
 
ebuild_compile() {
        if [ ! -d "${SRCDIR}" ]
        then
                echo "${SRCDIR} does not exist -- please unpack first."
                exit 1
        fi
        #make sure we're in the right directory
        cd ${SRCDIR}
        user_compile
}
 
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
 
if [ -e "$1" ]
then
        source $1
else
        echo "Ebuild file $1 not found."
        exit 1
fi
 
export SRCDIR=${WORKDIR}/${P}
 
case "${2}" in
        unpack)
                ebuild_unpack
                ;;
        compile)
                ebuild_compile
                ;;
        all)
                ebuild_unpack
                ebuild_compile
                ;;
        *)
                echo "Please specify unpack, compile or all as the second arg"
                exit 1
                ;;
esac
</source>
Notice '''/etc/ebuild.conf''' is sourced near the beginning of the file. Also, notice that we use <span style="color:green">$MAKEOPTS</span> in our default <span style="color:green">user_compile()</span> function. You may be wondering how this will work -- after all, we refer to <span style="color:green">$MAKEOPTS</span> before we source '''/etc/ebuild.conf''', which actually defines <span style="color:green">$MAKEOPTS</span> in the first place. Fortunately for us, this is OK because variable expansion only happens when <span style="color:green">user_compile()</span> is executed. By the time <span style="color:green">user_compile()</span> is executed, '''/etc/ebuild.conf''' has already been sourced, and <span style="color:green">$MAKEOPTS</span> is set to the correct value.
 
=== Wrapping it up ===
We've covered a lot of bash programming techniques in this article, but we've only touched the surface of the power of bash. For example, the production Gentoo Linux ebuild system not only automatically unpacks and compiles each package, but it can also:
 
* Automatically download the sources if they are not found in $DISTDIR
* Verify that the sources are not corrupted by using MD5 message digests
* If requested, install the compiled application into the live filesystem, recording all installed files so that the package can be easily uninstalled at a later date.
* If requested, package the compiled application in a tarball (compressed the way you like it) so that it can be installed later, on another computer, or during the CD-based installation process (if you are building a distribution CD)
 
In addition, the production ebuild system has several other global configuration options, allowing the user to specify options such as what optimization flags to use during compilation, and whether optional support for packages like GNOME and slang should be enabled by default in those packages that support it.
 
It's clear that bash can accomplish much more than what I've touched on in this series of articles. I hope you've learned a lot about this incredible tool, and are excited about using bash to speed up and enhance your development projects.
 
== Resources ==


* Download the source tarball ('''sed-3.02.tar.gz''') from ftp://ftp.gnu.org/pub/gnu/sed.
== Related ==
* Read [[Bash by example, Part1]].
* [[Flavors and Mix-ins]]
* Read [[Bash by example, Part 2]].
* Check out the [http://www.gnu.org/software/bash/manual/bash.html bash online reference manual].


__NOTOC__
[[Category:Funtoo features]]
[[Category:Linux Core Concepts]]
[[Category:Portage]]
[[Category:Articles]]
[[Category:Labs]]
{{ArticleFooter}}
[[Category:HOWTO]]
[[Category:Official Documentation]]

Revision as of 03:21, January 3, 2015

What is a profile?

In Gentoo and Funtoo Linux, profiles are used to define base system settings, and have historically had a lot of untapped potential. In Funtoo Linux, I wanted to take advantage of some of this potential to allow Funtoo Linux users to easily tailor their system for various types of roles. Enter the new Funtoo profile system.

What It Is

Historically, users have had to add a ton of settings to /etc/make.conf to customize their Gentoo or Funtoo Linux system, which made setup of the operating system more difficult than it should be.

In Gentoo Linux, it is possible to only define one system profile. Think of a system profile as the default settings that Portage uses for building everything on your system.

In Funtoo Linux, multiple profiles can be enabled at the same time. These include:

  • arch - one arch profile is enabled, at build time, and is not changed. This defines CPU architecture-specific settings.
  • build - one build profile is enabled, at build time, and is generally not changed. It defines the type of build, such as 'current' or 'stable', and associated settings.
  • flavor - one flavor is enabled per system, and can be changed by the user. This defines the general use of the system, such as 'minimal', 'core', 'workstation' or 'desktop'
  • mix-in - zero or more mix-ins can be enabled that enable settings specific to a particular subset of features, such as 'gnome', 'kde', 'media', 'mate', 'X', 'hardened'
   Note

See Flavors and Mix-ins for a complete list of all flavors and mix-ins available in Funtoo Linux, along with descriptions of what each one does.

Origins and Benefits

This new system is really a completion of the original cascading profile design that was designed by Daniel Robbins and implemented by Seemant Kulleen as part of Portage. Funtoo Profiles designed to leverage the existing cascading profile system and provide something much more useable and maintainable for users and developers alike. Here are some of its benefits:

  • Fewer settings in /etc/make.conf. CHOST and ARCH no longer set in /etc/make.conf.
  • Separation of concerns -- arch, build, and flavor-related settings are organized together.
  • User flexibility - any number of mix-ins can be enabled to tweak masks or USE settings as needed.
   Note

See Custom Profiles for information on how to extend the profile system.

Switch to the Funtoo 1.0 Profile

Using eselect

The preferred method of adding and removing profiles is to use eselect profile. This will ensure that profiles are added correctly and in the proper order. The order is imperative for things to work right.

Type the following to view a list of available options for eselect profile: 

root # eselect profile help


For a start, let's see what the default configuration has to offer. Get an overview using the list command: 

root # eselect profile list
root ##b##Currently available arch profiles:
  [1]   funtoo/1.0/linux-gnu/arch/x86-64bit * 
  [2]   funtoo/1.0/linux-gnu/arch/pure64
root ##b##Currently available build profiles:
  [3]   funtoo/1.0/linux-gnu/build/stable
  [4]   funtoo/1.0/linux-gnu/build/current * 
  [5]   funtoo/1.0/linux-gnu/build/experimental
root ##b##Currently available flavor profiles:
  [6]   funtoo/1.0/linux-gnu/flavor/minimal
  [7]   funtoo/1.0/linux-gnu/flavor/core *
  [8]   funtoo/1.0/linux-gnu/flavor/desktop
  [9]   funtoo/1.0/linux-gnu/flavor/workstation
  [10]  funtoo/1.0/linux-gnu/flavor/hardened
root ##b##Currently available mix-ins profiles:
  [11]  funtoo/1.0/linux-gnu/mix-ins/audio
  [12]  funtoo/1.0/linux-gnu/mix-ins/cinnamon
  [13]  funtoo/1.0/linux-gnu/mix-ins/console-extras
  [14]  funtoo/1.0/linux-gnu/mix-ins/dvd
  [15]  funtoo/1.0/linux-gnu/mix-ins/gnome
  [16]  funtoo/1.0/linux-gnu/mix-ins/kde
  [17]  funtoo/1.0/linux-gnu/mix-ins/mate
  [18]  funtoo/1.0/linux-gnu/mix-ins/media
  [19]  funtoo/1.0/linux-gnu/mix-ins/print
  [20]  funtoo/1.0/linux-gnu/mix-ins/python3-only
  [21]  funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
  [22]  funtoo/1.0/linux-gnu/mix-ins/server-db
  [23]  funtoo/1.0/linux-gnu/mix-ins/server-mail
  [24]  funtoo/1.0/linux-gnu/mix-ins/server-web
  [25]  funtoo/1.0/linux-gnu/mix-ins/X
  [26]  funtoo/1.0/linux-gnu/mix-ins/xfce
  [27]  funtoo/1.0/linux-gnu/mix-ins/vmware-guest
  [28]  funtoo/1.0/linux-gnu/mix-ins/hardened

As in several other Funtoo utilities, a star (*) on the right indicates an active item (your case may differ from the example above). In most cases you will want to set your "flavor" first. Remember that you can only set one flavor at time.

To choose your favorite flavor use the set-flavor command including your selection. In this example, we will set the desktop flavor:

   Note
You must use numbers to reference to the profiles you want.

root # eselect profile set-flavor 8

View the result: 

root # eselect profile list
root ##b##Currently available arch profiles:
  [1]   funtoo/1.0/linux-gnu/arch/x86-64bit * 
  [2]   funtoo/1.0/linux-gnu/arch/pure64
root ##b##Currently available build profiles:
  [3]   funtoo/1.0/linux-gnu/build/stable
  [4]   funtoo/1.0/linux-gnu/build/current * 
  [5]   funtoo/1.0/linux-gnu/build/experimental
root ##b##Currently available flavor profiles:
  [6]   funtoo/1.0/linux-gnu/flavor/minimal
  [7]   funtoo/1.0/linux-gnu/flavor/core
  [8]   funtoo/1.0/linux-gnu/flavor/desktop *
  [9]   funtoo/1.0/linux-gnu/flavor/workstation
  [10]  funtoo/1.0/linux-gnu/flavor/hardened
root ##b##Currently available mix-ins profiles:
  [11]  funtoo/1.0/linux-gnu/mix-ins/audio (auto)
  [12]  funtoo/1.0/linux-gnu/mix-ins/cinnamon
  [13]  funtoo/1.0/linux-gnu/mix-ins/console-extras (auto)
  [14]  funtoo/1.0/linux-gnu/mix-ins/dvd (auto)
  [15]  funtoo/1.0/linux-gnu/mix-ins/gnome
  [16]  funtoo/1.0/linux-gnu/mix-ins/kde
  [17]  funtoo/1.0/linux-gnu/mix-ins/mate
  [18]  funtoo/1.0/linux-gnu/mix-ins/media (auto)
  [19]  funtoo/1.0/linux-gnu/mix-ins/print (auto)
  [20]  funtoo/1.0/linux-gnu/mix-ins/python3-only
  [21]  funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
  [22]  funtoo/1.0/linux-gnu/mix-ins/server-db
  [23]  funtoo/1.0/linux-gnu/mix-ins/server-mail
  [24]  funtoo/1.0/linux-gnu/mix-ins/server-web
  [25]  funtoo/1.0/linux-gnu/mix-ins/X (auto)
  [26]  funtoo/1.0/linux-gnu/mix-ins/xfce
  [27]  funtoo/1.0/linux-gnu/mix-ins/vmware-guest
  [28]  funtoo/1.0/linux-gnu/mix-ins/hardened

As you see by the (auto) entries, the desktop flavor already pre-set some mix-ins for you.

Now, let's head over and add some mix-ins. To add, say, the mix-ins gnome and kde we'd have to enter: 

root # eselect profile add 15
root # eselect profile add 16

Or, in a one-shot: 

root # eselect profile add 15 16

If we want to remove a mix-in, for example gnome, simply enter: 

root # eselect profile remove 15

Verification: 

root # eselect profile list
root ##b##Currently available arch profiles:
  [1]   funtoo/1.0/linux-gnu/arch/x86-64bit * 
  [2]   funtoo/1.0/linux-gnu/arch/pure64
root ##b##Currently available build profiles:
  [3]   funtoo/1.0/linux-gnu/build/stable
  [4]   funtoo/1.0/linux-gnu/build/current * 
  [5]   funtoo/1.0/linux-gnu/build/experimental
root ##b##Currently available flavor profiles:
  [6]   funtoo/1.0/linux-gnu/flavor/minimal
  [7]   funtoo/1.0/linux-gnu/flavor/core
  [8]   funtoo/1.0/linux-gnu/flavor/desktop *
  [9]   funtoo/1.0/linux-gnu/flavor/workstation
  [10]  funtoo/1.0/linux-gnu/flavor/hardened
root ##b##Currently available mix-ins profiles:
  [11]  funtoo/1.0/linux-gnu/mix-ins/audio (auto)
  [12]  funtoo/1.0/linux-gnu/mix-ins/cinnamon
  [13]  funtoo/1.0/linux-gnu/mix-ins/console-extras (auto)
  [14]  funtoo/1.0/linux-gnu/mix-ins/dvd (auto)
  [15]  funtoo/1.0/linux-gnu/mix-ins/gnome
  [16]  funtoo/1.0/linux-gnu/mix-ins/kde *
  [17]  funtoo/1.0/linux-gnu/mix-ins/mate
  [18]  funtoo/1.0/linux-gnu/mix-ins/media (auto)
  [19]  funtoo/1.0/linux-gnu/mix-ins/print (auto)
  [20]  funtoo/1.0/linux-gnu/mix-ins/python3-only
  [21]  funtoo/1.0/linux-gnu/mix-ins/rhel5-compat
  [22]  funtoo/1.0/linux-gnu/mix-ins/server-db
  [23]  funtoo/1.0/linux-gnu/mix-ins/server-mail
  [24]  funtoo/1.0/linux-gnu/mix-ins/server-web
  [25]  funtoo/1.0/linux-gnu/mix-ins/X (auto)
  [26]  funtoo/1.0/linux-gnu/mix-ins/xfce
  [27]  funtoo/1.0/linux-gnu/mix-ins/vmware-guest
  [28]  funtoo/1.0/linux-gnu/mix-ins/hardened


No magic here, whatever you add gets put into the /etc/portage/make.profile/parent file by portage.

In our case, this file contains: 

root # cat /etc/portage/make.profile/parent
gentoo:funtoo/1.0/linux-gnu/arch/x86-64bit
gentoo:funtoo/1.0/linux-gnu/build/current
gentoo:funtoo/1.0/linux-gnu/flavor/desktop
gentoo:funtoo/1.0/linux-gnu/mix-ins/kde
   Warning

Please, do not add anything manually into parent file. This may result in profile breakage.

For Developers

Define the profile sub-sets you will use

So far in Funtoo we have used the exact same profiles as Gentoo thus Funtoo/2008.0 was strictly the same thing as Gentoo/2008.0 or the barely the same 10.0. This (monolithic) profile was set though a symbolic link named /etc/make.profile pointing on a complex directory architecture located somewhere under /usr/portage/profiles. This is no longer valid with the Funtoo 1.0 profiles as they are split in several smaller bricks which are then glued together via the /etc/portage/make.profile/parent file (You do not need to include everything, just use the "bricks" you need). Those bricks belongs to several categories:

  1. MANDATORY -- An "arch" profile which defines settings for a particular architecture. You'll want to set this to whatever arch your system is and leave it alone. Setting it to a different arch than your system could severely break it.
  2. MANDATORY -- A "build" profile which should match the tree you wish to use. Stable, Current (~arch), or Experimental (use it if you are brave enough and find current too stable).
  3. MANDATORY -- A "flavor" profile (what was previously known as profiles is still known as such in Gentoo) which describes the kind of system you want:
    • minimal - Be warned, minimal is exactly what it says, the minimal profile stuff you need for a usable system, nothing else. This is really for people who know what they're doing.
    • core - This is the core profile. This is for stuff that affects both desktops and servers.
    • desktop - Exactly what it says. If you're using a desktop, you should set this as your flavor.
    • server - If you're running a server, you should set this as your flavor.
  4. OPTIONAL -- One or more "mix-ins" profiles which describe optional add-ons. 'mix-ins' are the heart of the Funtoo 1.0 profiles. Unlike the monolithic profiles which sets a massive amount of use flags and options for you, we've split them into logical add-on profiles. For instance if you want support for gnome, you would add the gnome mix-in to your current profiles. That mix-in sets all the proper use flags and such for gnome. Same with others. Want dvd support? Add that one in. Using a rhel5 kernel which requires special versions of packages such as udev? There's a mix-in for that too. Run a mail server? web server? There's mix-ins for those also. Expect this category to grow in the future as new mix-ins are created.

The contents of /etc/portage/make.profile/parent for a basic setup might look like this:

   /etc/portage/make.profile/parent 
gentoo:funtoo/1.0/linux-gnu/arch/x86-64bit
gentoo:funtoo/1.0/linux-gnu/build/current
gentoo:funtoo/1.0/linux-gnu/flavor/core

A more rounded setup for a desktop might look like this:

   /etc/portage/make.profile/parent 
gentoo:funtoo/1.0/linux-gnu/arch/x86-64bit
gentoo:funtoo/1.0/linux-gnu/build/current
gentoo:funtoo/1.0/linux-gnu/flavor/desktop
gentoo:funtoo/1.0/linux-gnu/mix-ins/dvd
gentoo:funtoo/1.0/linux-gnu/mix-ins/media

Related

Retrieved from "https://www.funtoo.org/index.php?title=Bash_by_Example,_Part_3&oldid=8255"