Difference between pages "Java Configuration Design Update" and "Install/pt-br/Stage3"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
m (Tocadotux moved page Install/Stage3/es to Install/pt-br/Stage3/: Change of directory)
 
Line 1: Line 1:
This page describes a potential update to the Java support code in Gentoo and Funtoo Linux, with the intention of simplifying <tt>java-config</tt> code and also making it more correct and better integrated with Portage itself. The proposal intends to address deficiencies in the current design of <tt>java-utils-2.eclass</tt> while maintaining its useful features and avoiding a full rewrite. Rather than replace the current system with more code, the goal is to simplify the existing code while retaining functionality, while allowing a graceful migration of advanced functionality inside Portage itself.
=== Instalndo o Stage 3 tarball ===


{{fancytip|Please post comments on the [[{{TALKPAGENAME}}|Discussion]] page.}}
Depois de criar os  filesystems, o próximo passo é baixar o Stage 3 tarball inicial. O Stage 3 é um sistema pré-compiled utilizado como um ponto inicial para instalar o Funtoo Linux. Carregue um dos seguintes URLs em outra janela do navegador:


== Design Challenges ==
{{MirrorList}}


The current Java eclasses have some very interesting and powerful features, yet are lacking in some areas.
Agora, vamos navegar pelos diretórios nos mirrors para encontrar o build apropriado do  Funtoo Linux para você.


=== Dependency Handling ===
==== Qual Build? ====


Currently, <tt>java-utils-2.eclass</tt> uses <tt>depend-java-query</tt> to automatically select the most optimal Java VM for building. This is a sophisticated feature that is intended to be 'smart', yet it has some flaws. These flaws are fixable:
'''Se não estiver certo, escolha <code>funtoo-current</code>.'''


* While JVM auto-selection is smart, it is not always correct -- it doesn't use Portage's API, but instead uses regexes to parse the currently-executing ebuild's <tt>DEPEND</tt> string.
Funtoo Linux possui vários 'builds' diferentes, ou variantes. Here is a list of the various builds that are available, and what their distinctive features are:


* Related to the regex issue, the code in <tt>depend-java-query</tt> is complex as it tries to duplicate some functionality that could be handled better by Portage's API.
{{TableStart}}
<tr><th class="info">Build</th><th class="info">Description</th></tr>
<tr><td><code>funtoo-current</code></td><td>The most commonly-selected build of Funtoo Linux. Receives rapid updates and preferred by desktop users.</td></tr>
<tr><td><code>funtoo-current-hardened</code></td><td>Same package set as <code>funtoo-current</code>, but with a hardened, exploit-resistant toolchain.</td></tr>
<tr><td><code>funtoo-stable</code></td><td>Emphasizes less-frequent package updates and trusted, reliable versions of packages over the latest versions.</td></tr>
{{TableEnd}}


This proposal provides a mechanism for the Portage API to be used to always generate a completely correct result. This may seem like a minimal optimization since the existing code is correct ''most'' of the time. But it is duplicative, in that it does a rough approximation of what the Portage API could do absolutely correctly. So there is no good reason to keep it -- less code means more maintainability.
If you want to read more about this, have a look at [[Funtoo_Linux#What_are_the_differences_between_.27stable.27.2C_.27current.27_and_.27experimental.27_.3F|Differences between stable, current and experimental]].


{{fancyimportant|Moreover, there is even a better reason for doing things the right way -- eclasses should as much as possible be able to behave as "first-class citizens" in the world of Portage. This is an important architectural goal, and there are severe costs for not pursuing it, namely having every eclass under the sun re-implement various parts of Portage, albeit poorly, creating much uncessary code and frustration!}}
==== What Architecture?  ====


=== Atoms ===
'''If you're not sure, pick <code>x86-64bit</code>, or possibly <code>pure64</code> for server systems.'''


Currently, <tt>eselect java-vm</tt> and <tt>java-config</tt> have their own "atoms" that they use to identify Java virtual machines, which seems to be <tt>${PN}-${SLOT}</tt>. Yet Portage already has atoms, and we should try to allow support for them over time. This proposal does require there to be some "link" between the existing JVM atom and the Portage atom. This link currently does not exist.
For PC-compatible systems, the following choices are available:


== Proposal ==
{{TableStart}}
<tr><th class="info">Architecture</th><th class="info">Description</th></tr>
<tr><td><code>x86-64bit</code></td><td>For modern 64-bit processors. Uses new 64-bit instructions and address space. Maintains 32-bit compatibility with multilib.</td></tr>
<tr><td><code>pure64</code></td><td>For modern 64-bit processors but with no support for 32-bit compatibility.</td></tr>
<tr><td><code>x86-32bit</code></td><td>For older 32-bit systems such as Athlon XP, Pentium 4, or earlier Atom.</td></tr>
{{TableEnd}}


=== java-config Settings ===
==== Your SubArch ====


This proposal involves a minor upgrade to the java-config settings for a JVM -- adding a <tt>PORTAGE_ATOM</tt> setting to the file, which allows the <tt>java-config</tt> atom to be linked to the Portage atom:
Inside <code>/funtoo-current/x86-64bit/</code> on one of our mirrors, you'll see a bunch of directories for various ''subarches'' of Funtoo Linux. Subarches are builds of Funtoo Linux that are designed to run on a particular type of CPU, to offer the best possible performance. They also take advantage of the instruction sets available for each CPU.


{{file|name=/usr/share/java-config-2/vm/oracle-jdk-bin-1.7|desc=Java-config settings|lang=bash|body=
If you are using an AMD-based CPU, download a stage3 from <code>generic_64</code>, <code>amd64-k8</code>, <code>amd64-k10</code>, <code>amd64-bulldozer</code>, <code>amd64-piledriver</code>, <code>amd64-steamroller</code> or <code>amd64-jaguar</code>.  See [[Subarches#64-bit AMD Processors|our list of 64-bit AMD subarches]] for help figuring out which one is best for you.
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-java/oracle-jdk-bin/files/oracle-jdk-bin-1.7.env,v 1.2 2011/11/17 22:49:56 caster Exp $


VERSION="Oracle JDK 1.7.0.60"
If you are using an Intel-based CPU, download a stage3 from <code>generic_64</code>, <code>atom_64</code>, <code>core2_64</code> or <code>corei7</code>. Note that <code>corei7</code> is ideal for any modern Intel processor, including Core i3 and Core i5, and many Xeons. [[Subarches#64-bit Intel Processors|our list of 64-bit Intel subarches]] for help figuring out which one is best for you.
JAVA_HOME="/opt/oracle-jdk-bin-1.7.0.60"
JDK_HOME="/opt/oracle-jdk-bin-1.7.0.60"
JAVAC=${JAVA_HOME}/bin/javac
PATH="${JAVA_HOME}/bin:${JAVA_HOME}/jre/bin"
ROOTPATH="${JAVA_HOME}/bin:${JAVA_HOME}/jre/bin"
LDPATH="${JAVA_HOME}/jre/lib/amd64/:${JAVA_HOME}/jre/lib/amd64/xawt/:${JAVA_HOME}/jre/lib/amd64/server/"
MANPATH="/opt/oracle-jdk-bin-1.7.0.60/man"
PROVIDES_TYPE="JDK JRE"
PROVIDES_VERSION="1.7"
BOOTCLASSPATH="${JAVA_HOME}/jre/lib/resources.jar:${JAVA_HOME}/jre/lib/rt.jar:${JAVA_HOME}/jre/lib/sunrsasign.jar:${JAVA_HOME}/jre/lib/jsse.jar:${JAVA_HOME}/jre/lib/jce.jar:${JAVA_HOME}/jre/lib/charsets.jar:${JAVA_HOME}/jre/classes"
GENERATION="2"
ENV_VARS="JAVA_HOME JDK_HOME JAVAC PATH ROOTPATH LDPATH MANPATH"
VMHANDLE="oracle-jdk-bin-1.7"
BUILD_ONLY="FALSE"
PORTAGE_ATOM="dev-java/oracle-jdk-bin-1.7.0.60"
}}


With this very minor and easy-to-implement change, new possibilities are available -- namely, for <tt>java-config</tt> code to tap into the Portage API and leverage its advanced dependency handling functionality.
If you are using a 32-bit CPU, download a stage3 from <code>generic_32</code>, <code>i686</code>, <code>core2_32</code>, <code>atom_32</code> or <code>athlon-xp</code>.


<div style="float: right; width: 40%; margin-left: 1em; margin-top: 1em; margin-bottom: 1em; background-color: #f8f8f8; padding: 0.5em; border-radius: 8px;">
==== Setting the Date ====


=== Provides ===
{{fancyimportant|If your system's date and time are too far off (typically by months or years,) then it may prevent Portage from properly downloading source tarballs. This is because some of our sources are downloaded via HTTPS, which use SSL certificates and are marked with an activation and expiration date. However, if you system time is relatively close to correct, you can probably skip this step for now.}}


{{fancynote|This section is not a requirement for the implementation of this proposal, but a suggestion for future Portage development.}}
Now is a good time to verify the date and time are correctly set to UTC. Use the <code>date</code> command to verify the date and time:


Currently, the functionality that is provided by each JVM is stored in the <tt>java-config</tt> file shown above, namely in the <tt>PROVIDES_TYPE</tt> and <tt>PROVIDES_VERSION</tt> variables. This works for us, though it is unfortunate that the (in my opinion) not completely thought-out [http://wiki.gentoo.org/wiki/GLEP:37 GLEP 37] was implemented, which deprecated the <tt>PROVIDES</tt> variable in Portage. This is a useful variable because it gave us a "link" from the installed package to the virtual it provided. No such link currently exists, which is a reduction in useful functionality.
<console>
# ##i##date
Fri Jul 15 19:47:18 UTC 2011
</console>


It is recommended that <tt>PROVIDES</tt> is un-deprecated in Portage, and used by ebuilds solely for recording what virtuals are provided by the ebuild, so that they can be queried later once the package is installed. This would allow <tt>PROVIDES_TYPE</tt> and <tt>PROVIDES_VERSION</tt> -- functionality duplicated by the Java tools -- to be removed, further reducing the complexity of the Java tools codebase.
If the date and/or time need to be corrected, do so using <code>date MMDDhhmmYYYY</code>, keeping in mind <code>hhmm</code> are in 24-hour format. The example below changes the date and time to "July 16th, 2011 @ 8:00PM" UTC:
</div>


=== java-config Dependency Handling ===
<console>
# ##i##date 071620002011
Fri Jul 16 20:00:00 UTC 2011
</console>


With these changes, <tt>java-config</tt> and <tt>depend-java-query</tt> to tap directly into the power of Portage dependency handling. Let's see how.
Uma vez que você tenha definido o sistema de horário (system clock), é uma boa ideia copiar o horário para o sistema de horas do seu hardware (hardware clock), assim ele persiste nos reboots:


=== Query: List installed VMs ===
<console>
# ##i##hwclock --systohc
</console>


To list installed VMs, <tt>java-config</tt> could look in <tt>/usr/share/java-config-2/vm/</tt> to get a list of all installed Java VMs. However, thanks to the <tt>PORTAGE_ATOM</tt> variable, it can then compile a list of corresponding package atoms in <tt>/var/db/pkg</tt>.
==== Baixe o Stage3 ====
Uma vez que você está no root filesystem do seu Funtoo Linux, utilize <code>wget</code> para baixar o Stage 3 tarball que você escolheu utilizar como base para o seu novo sistema Funtoo Linux. Ele deve se salvo no direorio <code>/mnt/funtoo</code> como a seguir:


=== Query: Is a Suitable or Best VM Selected? ===
<console># ##i##cd /mnt/funtoo
# ##i##wget http://build.funtoo.org/funtoo-current/x86-64bit/generic_64/stage3-latest.tar.xz
</console>


Currently, the <tt>java-utils-2.eclass</tt> attempts to magically select the proper VM for building based on the contents of the <tt>DEPEND</tt> string. This is how this functionality would be implemented correctly, using the Portage API rather than custom code.
Note que sistemas 64-bit pode rodar stages 32-bit ou 64-bit, mas o sistema 32-bit podem somente rodar stages de 32-bit. Certifique-se de selecionar um Stage 3 que é apropriado para o seu CPU (processador). Se não estiver certo, é uma aposta segura escolher o stage <code>generic_64</code> ou <code>generic_32</code>. Consulte a página de [[Download]] para mais informações.


To perform this query correctly and efficiently, <tt>depend-java-query</tt> can compile a list of Portage atoms for all installed Java VMs, along with what virtual they provide using <tt>PORTAGE_ATOM</tt>, <tt>PROVIDES_TYPE</tt> and <tt>PROVIDES_VERSION</tt>. Then, the <tt>DEPEND</tt> handed to it can be correctly evaluated using Portage functions. This is how the Portage side of the algorithm would work:
Uma vez o stage for baixado, extraia os conteúdos com o seguinte comand, substituindo o nome nome real pelo seu stage 3 tarball:
<console>
# ##i##tar xpf stage3-latest.tar.xz
</console>


# Pre-process <tt>DEPEND</tt> string:
{{important|é muito importante utilizar <code>tar's</code> "<code>'''p'''</code>" option when extracting the Stage 3 tarball - it tells <code>tar</code> to ''preserve'' any permissions and ownership that exist within the archive. Without this option, your Funtoo Linux filesystem permissions will be incorrect.}}
## Remove all components that are not related to <tt>virtual/jdk</tt> and <tt>virtual/jre</tt>.
## Evaluate <tt>DEPEND</tt> string using currently-active USE settings to remove all conditionals.
# Create a <tt>fakedbapi</tt> and <tt>cpv_inject()</tt> the current system VM Portage atom into it.
# Evaluate the pre-processed <tt>DEPEND</tt> string and see if the dependencies are satisfied.
# If so, a suitable VM is selected.
 
To find the "best match" VM, a similar process would be followed. Instead of <tt>cpv_inject</tt>ing the current system VM, ''all'' installed VMs would be injected and a best match would be found.
 
== Future Directions ==
 
=== Reusing Code, Merging into Portage ===
 
Since this functionality could use useful to other eclasses, this could be used as a test for a more generic helper function that could be integrated into Portage. This would allow other eclasses to implement similar functionality without having to have their own custom helper applications.
 
The <tt>java-config</tt> settings file could be merged into <tt>/var/db/pkg</tt> and a simple API could be added to <tt>vartree</tt> and <tt>dblink</tt> to provide API access to it. This would provide a toolkit for eclasses for storing extra configuration settings with installed ebuilds, which could be useful for a variety of purposes.
 
All these goals support the idea of code re-use and maintainability, and addressing the problem at the correct architectural level.
 
[[Category:Portage]]
[[Category:FLOP]]
[[Category:Java]]
__NOEDITSECTION__

Revision as of 18:51, December 13, 2014

Instalndo o Stage 3 tarball

Depois de criar os filesystems, o próximo passo é baixar o Stage 3 tarball inicial. O Stage 3 é um sistema pré-compiled utilizado como um ponto inicial para instalar o Funtoo Linux. Carregue um dos seguintes URLs em outra janela do navegador:

Agora, vamos navegar pelos diretórios nos mirrors para encontrar o build apropriado do Funtoo Linux para você.

Qual Build?

Se não estiver certo, escolha funtoo-current.

Funtoo Linux possui vários 'builds' diferentes, ou variantes. Here is a list of the various builds that are available, and what their distinctive features are:

BuildDescription
funtoo-currentThe most commonly-selected build of Funtoo Linux. Receives rapid updates and preferred by desktop users.
funtoo-current-hardenedSame package set as funtoo-current, but with a hardened, exploit-resistant toolchain.
funtoo-stableEmphasizes less-frequent package updates and trusted, reliable versions of packages over the latest versions.

If you want to read more about this, have a look at Differences between stable, current and experimental.

What Architecture?

If you're not sure, pick x86-64bit, or possibly pure64 for server systems.

For PC-compatible systems, the following choices are available:

ArchitectureDescription
x86-64bitFor modern 64-bit processors. Uses new 64-bit instructions and address space. Maintains 32-bit compatibility with multilib.
pure64For modern 64-bit processors but with no support for 32-bit compatibility.
x86-32bitFor older 32-bit systems such as Athlon XP, Pentium 4, or earlier Atom.

Your SubArch

Inside /funtoo-current/x86-64bit/ on one of our mirrors, you'll see a bunch of directories for various subarches of Funtoo Linux. Subarches are builds of Funtoo Linux that are designed to run on a particular type of CPU, to offer the best possible performance. They also take advantage of the instruction sets available for each CPU.

If you are using an AMD-based CPU, download a stage3 from generic_64, amd64-k8, amd64-k10, amd64-bulldozer, amd64-piledriver, amd64-steamroller or amd64-jaguar. See our list of 64-bit AMD subarches for help figuring out which one is best for you.

If you are using an Intel-based CPU, download a stage3 from generic_64, atom_64, core2_64 or corei7. Note that corei7 is ideal for any modern Intel processor, including Core i3 and Core i5, and many Xeons. our list of 64-bit Intel subarches for help figuring out which one is best for you.

If you are using a 32-bit CPU, download a stage3 from generic_32, i686, core2_32, atom_32 or athlon-xp.

Setting the Date

   Important

If your system's date and time are too far off (typically by months or years,) then it may prevent Portage from properly downloading source tarballs. This is because some of our sources are downloaded via HTTPS, which use SSL certificates and are marked with an activation and expiration date. However, if you system time is relatively close to correct, you can probably skip this step for now.

Now is a good time to verify the date and time are correctly set to UTC. Use the date command to verify the date and time: 

root # date
Fri Jul 15 19:47:18 UTC 2011

If the date and/or time need to be corrected, do so using date MMDDhhmmYYYY, keeping in mind hhmm are in 24-hour format. The example below changes the date and time to "July 16th, 2011 @ 8:00PM" UTC: 

root # date 071620002011
Fri Jul 16 20:00:00 UTC 2011

Uma vez que você tenha definido o sistema de horário (system clock), é uma boa ideia copiar o horário para o sistema de horas do seu hardware (hardware clock), assim ele persiste nos reboots: 

root # hwclock --systohc

Baixe o Stage3

Uma vez que você está no root filesystem do seu Funtoo Linux, utilize wget para baixar o Stage 3 tarball que você escolheu utilizar como base para o seu novo sistema Funtoo Linux. Ele deve se salvo no direorio /mnt/funtoo como a seguir: 

root # cd /mnt/funtoo
root # wget http://build.funtoo.org/funtoo-current/x86-64bit/generic_64/stage3-latest.tar.xz

Note que sistemas 64-bit pode rodar stages 32-bit ou 64-bit, mas o sistema 32-bit podem somente rodar stages de 32-bit. Certifique-se de selecionar um Stage 3 que é apropriado para o seu CPU (processador). Se não estiver certo, é uma aposta segura escolher o stage generic_64 ou generic_32. Consulte a página de Download para mais informações.

Uma vez o stage for baixado, extraia os conteúdos com o seguinte comand, substituindo o nome nome real pelo seu stage 3 tarball: 

root # tar xpf stage3-latest.tar.xz
   Important

é muito importante utilizar tar's "p" option when extracting the Stage 3 tarball - it tells tar to preserve any permissions and ownership that exist within the archive. Without this option, your Funtoo Linux filesystem permissions will be incorrect.

Retrieved from "https://www.funtoo.org/index.php?title=Java_Configuration_Design_Update&oldid=7472"