1 |
On Tuesday 10 August 2004 23:55, Jason Stubbs wrote: |
2 |
> No Grand Unified Theory of Everything yet, but ... |
3 |
Almost there! |
4 |
|
5 |
I'll summarise the list of requirements that I see and then go through how |
6 |
they can solve various problems with regards to ${SUBJECT}. |
7 |
|
8 |
PROFILES |
9 |
packages.cc |
10 |
Defines a set of atoms that must be on the host system to be able to |
11 |
compile for this profile. |
12 |
bashrc - available as of portage-2.0.51_pre17 |
13 |
ARCH, USERLAND, LIBC & KERNEL are defined as those required for the |
14 |
package that is about to be compiled when sourced. Bashrc should define |
15 |
aliases for the toolchain to define how to compile for the host |
16 |
specified with a system of this profile. |
17 |
|
18 |
ATOMS |
19 |
cat/pkg&keyword |
20 |
Defines that a package needs to be compiled as the specified keyword. |
21 |
Portage expands the keyword to ARCH, USERLAND, LIBC & KERNEL and passes |
22 |
those to the host profile's bashrc. If an atom does not specify a |
23 |
keyword, it is taken to be that of the target root's profile. |
24 |
cat/pkg{atom [atom]} |
25 |
The braced atom specifies extra bounds for a matching cat/pkg's DSLOT. |
26 |
|
27 |
EBUILDS |
28 |
DSLOT="atom [atom ...]" |
29 |
Portage scans installed and to be installed packages against the |
30 |
specified atom(s) and builds the DSLOTted package once for each |
31 |
individual package match, passing the matched package name to the |
32 |
ebuild in the DSLOT variable. |
33 |
pkg_select() |
34 |
This function configures the system to use this package by default. If |
35 |
it is successful or if there is no need to do so, it should return 0. |
36 |
It should also export any information needed to revert the system back |
37 |
to its original state. If it is not successful, it should do any |
38 |
cleanup required immediately and return 1. |
39 |
pkg_revert() |
40 |
This function reverts the system to back to the state it was in before |
41 |
running pkg_select() based on information exported by pkg_select(). |
42 |
|
43 |
INSTALLED DB |
44 |
/var/db/pkg/keyword/cat/pkg-ver[--pkg-ver] |
45 |
The keyword is taken or inferred from the cat/pkg&keyword specified for |
46 |
the installed package. The [-pkg-ver] component represents the DSLOTted |
47 |
version of the package. |
48 |
|
49 |
Not too much I hope... Anyway, on to how I envision it working. |
50 |
|
51 |
|
52 |
MOD_PHP |
53 |
|
54 |
DEPEND would simply contain "net-www/apache" without respect to USE flags as |
55 |
well as any other DEPENDs it might have. DSLOT would also contain |
56 |
"net-www/apache". Apache doesn't need to do any special setup and so would |
57 |
simply return a 0 for both pkg_select() and pkg_revert(). In the case that |
58 |
both apache-1.3.31-r2 and apache-2.0.50 are installed, portage would elect to |
59 |
install mod_php twice, passing in the different versions of apache each time. |
60 |
Each installation would end up in a directories under /var/db/pkg labelled |
61 |
mod_php-4.3.8--apache-1.3.31-r2 and mod_php-4.3.8--apache-2.0.50. |
62 |
|
63 |
As for differing use flags, users could specify them in package.use using the |
64 |
new atom syntax. For example, "dev-php/mod_php{=apache-2*} -mysql". Users |
65 |
could also restrict the combination by way of package.mask. If they wanted |
66 |
both apache-1 and apache-2 installed but only wanted mod_php for apache-2, |
67 |
for example, a user could specify "dev-php/mod_php{=apache-1*}" in |
68 |
package.mask and so on and so forth. |
69 |
|
70 |
NVIDIA_KERNEL |
71 |
|
72 |
The only required change would be DSLOT="virtual/linux-sources" as the ebuild |
73 |
already detects what kernel version is at /usr/src/linux and compiles against |
74 |
it. The kernels, on the other hand, would define pkg_select() to change the |
75 |
linux symlink to its own sources and export what was previously linked. Then |
76 |
in pkg_revert() it would restore the symlink to its original state. |
77 |
|
78 |
OTHERS |
79 |
|
80 |
The only other that I know of, ocaml, could use the pkg_select() function to |
81 |
run ocaml-config to set the compiler to the version required. Any package |
82 |
that needs to be slotted based on the version of another package should be |
83 |
able to be done so in pretty much the same way. |
84 |
|
85 |
GCC |
86 |
|
87 |
To build a cross compiler, the atom would be "sys-devel/gcc&keyword". Gcc |
88 |
would then receive the keyword in the form of ARCH, USERLAND, LIBC & KERNEL |
89 |
but would still be able to tell the host architecture by way of the keyword |
90 |
'USE flag'. Portage would then slot the compiler into /var/db/pkg/keyword/. |
91 |
Gcc would also define pkg_select() and pkg_revert() to do the same as ocaml. |
92 |
|
93 |
CROSS COMPILATION |
94 |
|
95 |
A "chroot" would be created and the profile set. Any other files (such as |
96 |
make.conf, et al) would also be created before any emerging starts. The |
97 |
profile then dictates what tools are required from the host by way of |
98 |
packages.cc. In a sparc profile, for example, would be "sys-devel/gcc&sparc". |
99 |
Portage would then emerge gcc into the host system as specified above. |
100 |
|
101 |
When packages are to be merged into the "chroot", portage will look at the |
102 |
packages.cc and run pkg_select() on each tool required before doing the |
103 |
compilation and merging and then run pkg_revert() after each. |
104 |
|
105 |
MULTILIB |
106 |
|
107 |
I'll use amd64 as the example. In the profile, bashrc would set aliases |
108 |
defining how to run gcc to create 32bit binaries when ARCH="x86". The |
109 |
profile's ACCEPT_KEYWORDS would be "amd64 x86". When keyword matching is |
110 |
done, they are search in order of ACCEPT_KEYWORDS and the first match is used |
111 |
when sourcing bashrc and when recording the installation into the installed |
112 |
package database. |
113 |
|
114 |
Any packages that the to be installed package depends on will then be |
115 |
installed using the accepted keyword. |
116 |
|
117 |
|
118 |
I'm sure there are a few issues remaining here. I think that most of them will |
119 |
be much easier to deal with, though. Feedback is greatly welcome. |
120 |
|
121 |
Regards, |
122 |
Jason Stubbs |
123 |
|
124 |
-- |
125 |
gentoo-dev@g.o mailing list |