| 1 |
grobian 08/01/05 12:21:21 |
| 2 |
|
| 3 |
Added: usecases.xml |
| 4 |
Log: |
| 5 |
Add usecases doc. It is actually a GuideMLed version of my tex sources for the article in Linux+ magazine, Gentoo edition. Since that whole party was cancelled, the article may serve some purpose, instead of chancelessly rotting away on one of my disks. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: usecases.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version="1.0" encoding="UTF-8"?> |
| 16 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 17 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml,v 1.1 2008/01/05 12:21:20 grobian Exp $ --> |
| 18 |
|
| 19 |
<guide link="/proj/en/gentoo-alt/prefix/usecases.xml" lang="en"> |
| 20 |
<title>Gentoo Prefixed Portage Use Cases</title> |
| 21 |
|
| 22 |
<author title="Author"> |
| 23 |
<mail link="grobian@g.o">Fabian Groffen</mail> |
| 24 |
</author> |
| 25 |
|
| 26 |
<abstract> |
| 27 |
Use cases for a Prefixed environment. |
| 28 |
</abstract> |
| 29 |
|
| 30 |
|
| 31 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 32 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 33 |
<license/> |
| 34 |
|
| 35 |
<version>1.0</version> |
| 36 |
<date>2008-01-05</date> |
| 37 |
|
| 38 |
<chapter> |
| 39 |
<title>Gentoo/Alt:Prefix - what's in it?</title> |
| 40 |
|
| 41 |
<section><!-- {{{ Introduction --> |
| 42 |
<title>Introduction</title> |
| 43 |
<body> |
| 44 |
|
| 45 |
<p> |
| 46 |
Usually when one thinks of Gentoo, its Linux distribution |
| 47 |
comes to mind. However, there is more that Gentoo has to |
| 48 |
offer. To the extreme, Gentoo has its <e>Alt</e> project that |
| 49 |
deals with non-Linux operating systems. Most visible in |
| 50 |
Gentoo/Alt are currently the BSD and Prefix projects. While |
| 51 |
the former focusses on providing some form of Gentoo on all |
| 52 |
kinds of BSD systems, the latter targets nearly every platform |
| 53 |
including Gentoo Linux itself. What both have in common, is |
| 54 |
that they use Gentoo Portage to install software on the target |
| 55 |
systems. |
| 56 |
</p> |
| 57 |
<p> |
| 58 |
Among the various Linux distributions, Gentoo is one of the |
| 59 |
few that is source based. In fact, Gentoo is a |
| 60 |
meta-distribution, which more or less means that Gentoo |
| 61 |
provides <e>how</e> to install a package, instead of the |
| 62 |
package itself in a binary form. This property allows to |
| 63 |
easily <e>reuse</e> the meta-data that exists for a package to |
| 64 |
install it on another kind of platform. This is one of the |
| 65 |
reasons why the Gentoo Linux distribution targets so many |
| 66 |
(rare) architectures: reuse allows for easy maintenance. The |
| 67 |
Gentoo/Alt project builds further on this particular property. |
| 68 |
With relatively small efforts, the meta-packages (ebuilds) can |
| 69 |
be made to install from the same sources on non-Linux |
| 70 |
operating systems. |
| 71 |
</p> |
| 72 |
<p> |
| 73 |
In this article we focus on the Prefix project. The project |
| 74 |
itself is experimental, thus not intended for use in any |
| 75 |
settings where an experimental nature is not appreciated, such |
| 76 |
as production environments. However, the early experiences |
| 77 |
with the project are interesting enough to be discussed in |
| 78 |
this article. Gentoo Prefix has some unusual properties, |
| 79 |
which makes it useful for a number of occasions. Two use |
| 80 |
cases follow. |
| 81 |
</p> |
| 82 |
|
| 83 |
</body> |
| 84 |
</section><!-- }}} --> |
| 85 |
|
| 86 |
<section><!-- {{{ Use Cases --> |
| 87 |
<title>Use Cases</title> |
| 88 |
<body> |
| 89 |
|
| 90 |
<p><b>Case 1: A student at the University</b></p> |
| 91 |
<p> |
| 92 |
A student X wants to compile and run some self-developed |
| 93 |
software on the Sun workstations provided by his university. |
| 94 |
The development tools required for the student's project go |
| 95 |
far beyond what the system administrators like to install, and |
| 96 |
other than that, they don't have time to look into it. With |
| 97 |
the student obviously having no administrative privileges to |
| 98 |
the Sun workstations, he cannot "just" install the required |
| 99 |
software tools himself. Even if the student wants to use |
| 100 |
non-official package installers, he still needs administrative |
| 101 |
privileges, as those installers like to place the binaries in |
| 102 |
places which by default are not writeable for the student. |
| 103 |
The only option left for the student is to compile and install |
| 104 |
the software he needs manually himself. This typically |
| 105 |
requires some time, expertise and work. Not always does |
| 106 |
software compile out of the box. Sometimes due to |
| 107 |
"dependencies" on other packages, and quite often a number |
| 108 |
of packages needs to be installed in the right order before it |
| 109 |
all works. A lot of work, just to get the self-developed |
| 110 |
package only to compile. |
| 111 |
</p> |
| 112 |
|
| 113 |
<p><b>Case 2: Companies deploying software</b></p> |
| 114 |
<p> |
| 115 |
Company Y has its own product P. By the nature of P, it is |
| 116 |
compiled at the customer's machines, highly tuned and |
| 117 |
configured for the customer's needs. Also the maintenance, |
| 118 |
patches and requirement changes are done by Y. Unfortunately, |
| 119 |
the customers of Y are very much bound to the machines and |
| 120 |
operating systems they use on that. Big contracts, and |
| 121 |
secured "trust" in the form of SLAs and years of experience |
| 122 |
make Y's customers want to use whatever they have been using |
| 123 |
for years. Even though administrative privileges are within |
| 124 |
reach of Y for the systems to build on, Y likes to avoid that |
| 125 |
since not only Y's software runs on the systems. A fix for |
| 126 |
one, can break things for the other. The nature of Y's |
| 127 |
customers simply doesn't allow breakage, hence changing the |
| 128 |
system is the very last resort. However, for Y to install its |
| 129 |
product, it needs some more recent, or extra development |
| 130 |
tools. Like the student from case 1, the only option left, is |
| 131 |
to manually compile and install what is necessary, including |
| 132 |
the burden of tracking the "dependencies". |
| 133 |
</p> |
| 134 |
|
| 135 |
<p> |
| 136 |
Next to these two use cases, many others exist. It is not |
| 137 |
hard to think of not being at an university, but on a company |
| 138 |
workstation or laptop. Or just that a user doesn't like to |
| 139 |
"pollute" the main system by installing (non-vendor) |
| 140 |
packages. In all cases, Gentoo Prefix provides a solution. |
| 141 |
Simply put, Gentoo Prefix allows to install packages from |
| 142 |
source, without administrative privileges, into a custom |
| 143 |
location in the file system hierarchy (the prefix). Since |
| 144 |
Gentoo Prefix uses the Portage package manager, it also deals |
| 145 |
with all (possible) dependencies, and compile time options to |
| 146 |
enable or disable certain functionality. Last, but not least, |
| 147 |
the packages provided are -- as usual within Gentoo -- fairly |
| 148 |
up-to-date, so the chance for "outdated software" is really |
| 149 |
small. |
| 150 |
</p> |
| 151 |
|
| 152 |
</body> |
| 153 |
</section><!-- }}} --> |
| 154 |
|
| 155 |
<section><!-- {{{ Installing Gentoo Prefix --> |
| 156 |
<title>Installing Gentoo Prefix</title> |
| 157 |
<body> |
| 158 |
|
| 159 |
<p> |
| 160 |
How does Gentoo Prefix work then? Without the details, it |
| 161 |
works like a normal Gentoo Linux system: packages are simply |
| 162 |
<e>emerged</e>. However, before one can do that, Gentoo |
| 163 |
Prefix first has to be installed. While at this time of |
| 164 |
writing there is no installer or live-CD, the only way to |
| 165 |
install Gentoo Prefix is by bootstrapping using a special |
| 166 |
script. Detailed descriptions of how to do that on for |
| 167 |
example Mac OS X can be found on the project website. |
| 168 |
Installing via that documentation remains the only way for as |
| 169 |
long as "one button" installers are not available. For users |
| 170 |
that are familiar with installing Gentoo Linux without the |
| 171 |
installer just by following the documentation, will find some |
| 172 |
resemblance in how Gentoo Prefix is installed. Step by step |
| 173 |
instructions, with per step explanation of why and what for. |
| 174 |
</p> |
| 175 |
|
| 176 |
<p> |
| 177 |
The bootstrapping process consists of three phases, 1) |
| 178 |
installing the core tools, 2) using Portage to emerge a base |
| 179 |
system, and 3) using portage to rebuild all of the installed |
| 180 |
packages with custom optimisations and features. |
| 181 |
</p> |
| 182 |
|
| 183 |
<p> |
| 184 |
While the whole process is boring overall, it results in an |
| 185 |
up-to-date and ready to use developer (sub-)system. Phase 1) |
| 186 |
is mainly installing the tools that Portage itself needs to |
| 187 |
function properly. Packages that are installed here are a |
| 188 |
recent Python, findutils, and so on, in total a number of 10 |
| 189 |
packages. The final step of this phase is to install Portage |
| 190 |
itself. This allows to continue with the next phase, where |
| 191 |
packages are only installed using Portage. Phase 2) starts by |
| 192 |
<e>emerging</e> build utilities in an order such that |
| 193 |
dependencies are met. Because these utilities are so |
| 194 |
"basic", Portage often doesn't take them into account as |
| 195 |
package dependencies, since they belong to the <e>base |
| 196 |
profile</e>. Hence, the dependency calculation of Portage |
| 197 |
will not create a correct graph for these packages, resulting |
| 198 |
in failures during compilation. For this reason, A number of |
| 199 |
packages is emerged without dependency calculation in a fixed |
| 200 |
order. After this the final step of this phase is to use the |
| 201 |
dependency system of Portage to emerge the special target |
| 202 |
"system", which includes all the packages that should be |
| 203 |
available on a system to function properly. Once all these |
| 204 |
packages are available, the last phase, 3), can be executed. |
| 205 |
In this final phase, the tree with ebuilds is updated to the |
| 206 |
most current version, and the compile time flags and features |
| 207 |
can be set. After that, it mainly does a recompilation of all |
| 208 |
packages compiled before, and adds some packages that may be |
| 209 |
necessary for the updated features ("USE flags"). While |
| 210 |
recompiling all packages previously compiled may sound like a |
| 211 |
waste of time, it is done on purpose. First, in order to have |
| 212 |
the new compile time flags become active, packages have to be |
| 213 |
<e>re-emerged</e>. Since these compile time flags (CFLAGS) |
| 214 |
often contain optimisations which greatly affect the speed and |
| 215 |
performance of the utilities, it is worth to recompile for |
| 216 |
this. Second, packages emerged in the second phase, sometimes |
| 217 |
still use tools provided by the operating system being built |
| 218 |
on, instead of those tools installed by Portage. These need |
| 219 |
to be corrected, which is done by a recompilation. |
| 220 |
</p> |
| 221 |
|
| 222 |
<p> |
| 223 |
After these phases, the (sub-)system is ready for use, and |
| 224 |
packages of choice can be emerged in the system. These |
| 225 |
packages can be libraries (libpcre, libxml2, ...), |
| 226 |
applications (vim, mutt, ...) or whole graphical toolkits, |
| 227 |
such as QT and GTK. |
| 228 |
<!-- currently this doesn't work, so let's not mention it |
| 229 |
And among contributions, also the |
| 230 |
utilities for a typical LAMP setting are supported by Gentoo |
| 231 |
Prefix. Apache, PHP, PostgreSQL, all working, without |
| 232 |
administrative privileges. |
| 233 |
--> |
| 234 |
</p> |
| 235 |
|
| 236 |
</body> |
| 237 |
</section><!-- }}} --> |
| 238 |
|
| 239 |
<section><!-- {{{ What is this Prefix? --> |
| 240 |
<title>What is this Prefix?</title> |
| 241 |
<body> |
| 242 |
|
| 243 |
<p> |
| 244 |
So far we have discussed what one can do with Gentoo Prefix. |
| 245 |
The curious reader, however, may wonder how it is done, and |
| 246 |
why it can do all of this installing without causing trouble. |
| 247 |
The first thing that needs some explanation, is the name of |
| 248 |
the project itself: Prefix. A prefix is some part put "in |
| 249 |
front of" something else. In this case, it is a path put in |
| 250 |
front of all other paths that Portage deals with. The main |
| 251 |
reason why administrative privileges are often required, is |
| 252 |
because the software is finally installed into a location that |
| 253 |
a normal user in the system can write to. This is good, as it |
| 254 |
protects the system from getting broken by mistakes from |
| 255 |
unknowing users, but prevents the user from installing the |
| 256 |
software. So the approach taken in Prefix Portage is to |
| 257 |
deviate from these default locations, and shift everything |
| 258 |
into an <e>offset</e>. This offset, which is prefixed to every |
| 259 |
path Portage uses, can be freely chosen. This way, a user can |
| 260 |
install into his own home directory, or to some large disk |
| 261 |
space location which he has write permissions for. And here |
| 262 |
is the reason why Prefix works for what it wants. It installs |
| 263 |
into there where the user has full privileges to do what is |
| 264 |
necessary: installing software. |
| 265 |
</p> |
| 266 |
|
| 267 |
<p> |
| 268 |
Guarded with this offset, knowing that everything is installed |
| 269 |
into this location, usage of the prefix consists of using |
| 270 |
everything from this prefix, before even looking at what the |
| 271 |
main operating system has installed. This is what Portage in |
| 272 |
the prefix does. It simply changes the search paths such that |
| 273 |
the prefix comes first. Simple as that, as far as Portage is |
| 274 |
concerned. Knowledgeable readers on compiler and linker |
| 275 |
workings will immediately wonder how Portage deals with them |
| 276 |
and the offset. The simple answer is that compilers and |
| 277 |
linkers installed by Portage in the prefix are configured such |
| 278 |
that they look into the prefix first as well. Not only that, |
| 279 |
but also does it make sure that compiled programs will keep on |
| 280 |
looking in the prefix via <e>rpath</e> directions, which are a |
| 281 |
bit too detailed for this article to discuss. The conclusion |
| 282 |
is that programs compile and run using prefix provided tools |
| 283 |
and libraries. |
| 284 |
</p> |
| 285 |
|
| 286 |
</body> |
| 287 |
</section><!-- }}} --> |
| 288 |
|
| 289 |
<section><!-- {{{ Conclusions --> |
| 290 |
<title>Conclusions</title> |
| 291 |
<body> |
| 292 |
|
| 293 |
<p> |
| 294 |
Gentoo Prefix is an easy way to enable using software |
| 295 |
installed on a user base. This in particular is interesting |
| 296 |
for situations where administrative privileges are not |
| 297 |
available or simply not suitable. Gentoo Prefix is like Fink, |
| 298 |
MacPorts or pkgsrc for Mac OS X systems, but not limited to |
| 299 |
this operating system alone. The nature of Portage -- from |
| 300 |
the Gentoo philosophy -- allows fine grained control over how |
| 301 |
packages are installed, which is brought to users of many |
| 302 |
platforms. Last but absolutely not least, we like to stress |
| 303 |
that Gentoo Prefix is not a "finished" product. It is a |
| 304 |
proof-of-concept that currently (quite successful) explores |
| 305 |
the possibilities of using Gentoo Portage on systems other |
| 306 |
than Gentoo Linux. Unprivileged installation of Gentoo Prefix |
| 307 |
is one of the drives that allow the project to be quite |
| 308 |
successful so far. |
| 309 |
</p> |
| 310 |
|
| 311 |
</body> |
| 312 |
</section><!-- }}} --> |
| 313 |
|
| 314 |
</chapter> |
| 315 |
|
| 316 |
</guide> |
| 317 |
|
| 318 |
<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable: --> |
| 319 |
<!-- kate: space-indent on; indent-width 2; replace-tabs on; --> |
| 320 |
|
| 321 |
|
| 322 |
|
| 323 |
-- |
| 324 |
gentoo-commits@g.o mailing list |
Archives