1 |
Hi all, |
2 |
|
3 |
In accordance with drobbins' wishes, the discussion of the new Portage job |
4 |
system moves to gentoo-dev. This is a quick summary of the discussion on |
5 |
#gentoo yesterday. |
6 |
|
7 |
The idea as of now is this: (my version) |
8 |
|
9 |
|
10 |
Intro: |
11 |
-------- |
12 |
Under profiles/jobs, or in a similar location, will be a job dir (Possibly |
13 |
profiles/default/jobs, and the references may then be redirected through |
14 |
/etc/make.profile). Developers can place jobs in it for Portage to execute. |
15 |
|
16 |
Jobs can request to be run once, or many times based on a condition. Portage |
17 |
will keep track of jobs that have been run in e.g. /var/db/jobs. |
18 |
|
19 |
|
20 |
Helper files: |
21 |
---------------- |
22 |
Jobs can have misc files, a separate dir should be given to these i.e. |
23 |
profiles/jobs/files. |
24 |
|
25 |
|
26 |
Generic scripts: |
27 |
-------------------- |
28 |
Provide a dir profiles/jobs/scripts and populate it with *generic* scripts. |
29 |
Under profiles/jobs put job spec files which, in their first few (commented |
30 |
out) lines, have info about when to run them, and then have a #! line that |
31 |
specifies one of these generic scripts as the interpreter. For example, a job |
32 |
spec for moving a package would be called move-koffice.job, and begin: |
33 |
|
34 |
# Job spec description: move the koffice package from kde-apps to app-office |
35 |
# Run Once |
36 |
# Author: Dan Armak <danarmak@g.o> |
37 |
# $Header: $ |
38 |
#! /usr/portage/profiles/jobs/scripts/movepackage.sh |
39 |
move koffice kde-apps app-office |
40 |
... |
41 |
and so on, from here script-specific info would follow. This is the best |
42 |
model IMHO. |
43 |
Of course, under this model a job file can still be a script in its own |
44 |
right, and use none of the generic scripts. |
45 |
|
46 |
|
47 |
The Portage-handled header: (I don't like this but have no better idea) |
48 |
-------------------------------------------------------------------------------------- |
49 |
It can specify: |
50 |
1. Name |
51 |
2. Revision |
52 |
3. Author |
53 |
4. Date |
54 |
5. Condition for running: |
55 |
The simplest method: jobs are sorted into 3 groups, in three separate dirs: |
56 |
1. Run once as soon as possible and never run again. |
57 |
2. Run on-demand only. For example, jobs to configure a program after merging. |
58 |
3. Run whenever all jobs are run, i.e. after emerge rsync. The job (i.e. |
59 |
script) itself will decide whether to take any action. |
60 |
|
61 |
Note that this is cluttering and not very elegant. Jobs should be able to run |
62 |
many times, than tell portage not to run them any more. But, making portage |
63 |
evaluate a special-syntax run condition is such a bother. Please give new |
64 |
ideas for this. |
65 |
|
66 |
|
67 |
When to run - options: |
68 |
----------------------------- |
69 |
1. The jobs will be executed after each run of emerge, including emerge rsync. |
70 |
|
71 |
2. Before each run of emerge, to accommodate the following scenario: change |
72 |
in cvs requires job to run before any emerges. |
73 |
|
74 |
3. Before/after runs of ebuild as well. (Probably not). |
75 |
|
76 |
4. Provide "emerge jobs" command to run on demand. |
77 |
|
78 |
|
79 |
Ideas/needs for jobs: |
80 |
--------------------------- |
81 |
1. Move a package to a different category, update /var/db/pkg if the package |
82 |
was already installed. This is what we're doing with kde/gnome. |
83 |
|
84 |
2. Output some info to the user. For example about an important new change in |
85 |
Portage/emerge/new KDE version etc., for the users who don't read the cvs |
86 |
logs or gentoo-dev. |
87 |
|
88 |
3. Merge a new version of sys-apps/portage when this is needed for some |
89 |
ebuilds' new versions to work, like in the \" story. A user who got the new |
90 |
ebuilds with non-escaped quotes but didn't update portage would be in big |
91 |
trouble. |
92 |
|
93 |
4. After merging a package, output usage intructions. Deprecate the |
94 |
pkg_postinst usage, emerge outputs info after it anyway. |
95 |
|
96 |
5. As above, run a configuration program. |
97 |
|
98 |
6. Manage a bug report system. A user who got an error running one of uor |
99 |
ebuilds would get this job executed. |
100 |
... |
101 |
|
102 |
|
103 |
Please add ideas! |
104 |
|
105 |
-- |
106 |
|
107 |
Dan Armak |
108 |
Gentoo Linux Developer, Desktop Team |
109 |
Matan, Israel |