This is a graphical installer for Ubuntu, written largely in Python, using d-i as a backend for many of its functions. The authors are indebted to the efforts of the Guadalinex project in developing the original "ubuntu-express" code used as a basis for this project.
Background
Around 2000, the debian-installer (later just "d-i") project started to replace the old Debian "boot-floppies" installer. The goals of this project included long-term maintainability, modularity, and code reuse. After a hiatus during the Debian 3.0 release, this project matured into a usable installer in 2004 in time for, among others, the releases of Debian 3.1 and Ubuntu 4.10. From Ubuntu 4.10 to Ubuntu 5.10, d-i was used as the primary installation program. d-i continues to provide flexibility and (for a certain significant class of users) ease of use that a simplified graphical installer will always be hard-pushed to provide. It is therefore important to continue to support it
23 in Ubuntu. From a maintainability point of view, it follows that it is
24 important for any graphical installer supported by Ubuntu to share
25 substantial amounts of code with d-i, particularly where the backend logic
26 is intrinsically difficult and has accumulated large quantities of expertise
27 and bug fixes. Accordingly, Ubiquity is designed to use logic from d-i where
28 possible, and tries to confine itself to being a high-quality frontend.
29
30 (Of course, there remain some areas where d-i does not provide suitable
31 logic, or where its logic has not proven amenable to direct use within
32 Ubiquity, so there is still some backend-style logic and code duplication
33 in Ubiquity. Eventually, as much of this as possible should go away.)
34
35 UI Design
36 ---------
37
38 The primary focus of Ubiquity's UI is ease of use for new users.
39 Accordingly, it does not try to provide all possible options, deferring
40 advanced installation scenarios to d-i so that it does not have to be all
41 things to all people. See http://wiki.ubuntu.com/UbuntuExpress for the
42 original details of its user interface design.
43
44 Debconf Integration
45 -------------------
46
47 The most challenging part of Ubiquity to understand is undoubtedly its
48 integration with d-i. Before getting to grips with this, I assume that the
49 reader has a basic developer-level grasp of the "debconf" configuration
50 system. Reading the debconf-devel(7) man page is a good idea.
51
52 d-i uses debconf for all user interaction. The extant graphical debconf
53 frontends are functional, but crude from a human interface design
54 perspective; although this could be improved, the problem is to some extent
55 intrinsic because they must generate a user interface based on the questions
56 asked by the confmodule. It is possible to do much better using custom user
57 interface code. However, at present debconf has no support for doing this
58 directly (although cdebconf does).
59
60 To deal with this, Ubiquity uses the noninteractive debconf frontend, and
61 instead uses a layer called the "debconffilter". This sits between d-i code
62 and the debconf frontend, intercepting the debconf protocol, and transforms
63 relevant debconf protocol messages into events which can be handled in much
64 the same way as UI events from widget libraries like GTK+ or Qt. While this
65 requires insider knowledge of the questions which may be asked by each piece
66 of d-i code, which must often be updated as d-i evolves, it seems to be the
67 most practical approach at present.
68
69 Each piece of d-i code used in Ubiquity is accompanied by a "component",
70 written in Python, which defines the backend code to be called and any
71 necessary event handlers. To allow for multiple frontend implementations, it
72 typically calls methods in the frontend when UI operations are needed.
73
74 It is important to remember that each call to component event handlers is
75 blocking (though non-reentrant). If UI interaction is required in order to
76 provide an answer to debconf, this must be handled by calling into suitable
77 frontend functions from the component to wait for the user. The component is
78 responsible for maintaining its own state machine if necessary.
79
80 Partitioning
81 ------------
82
83 2037 All partitioning is handled by d-i code (partman), with a presentation layer
84 on top. The presentation layer navigates partman's menus under the hood to
85 perform advanced partitioning. See
86 http://wiki.ubuntu.com/Ubiquity/AdvancedPartitionerRewrite for details.
87
88 A graphical disk view has yet to be written for the GTK frontend's advanced
89 partitioner.
90 1483
91 Installation
92 ------------
93
94 The actual installation takes place by copying the read-only part of the
95 live filesystem. The writable part of the live filesystem (i.e. the running
96 live session) is intentionally not copied, to ensure maximum reproducibility
97 of the installed system. Thus, any customisations applied by the live boot
98 process must be re-applied after the read-only filesystem is copied. The
99 live boot process is responsible for installing hooks in
100 /usr/lib/ubiquity/target-config/ to take care of this.
101
102 After copying the live filesystem, certain unnecessary packages (such as
103 Ubiquity itself) will be removed. The set of packages to be removed is
104 computed by taking those packages present in
105 /cdrom/casper/filesystem.manifest but not present in
106 /cdrom/casper/filesystem.manifest-desktop, and removing any packages
107 explicitly requested for installation by installer code. Language packs for
108 languages which are not to be supported on the installed system will also be
109 removed.
110
111 1500 Logs of the installation will be saved in /var/log/syslog (for messages
112 emitted by Ubiquity itself and messages emitted by d-i code), and
113 /var/log/partman (for a trace of the operation of the automatic
114 partitioner). /var/log/syslog and /var/log/partman are saved in
115 /var/log/installer/ on the installed system.
116 1483
117 Customisation
118 -------------
119
120 Where d-i code is used, it is generally possible to preseed it to change
121 2719.1.1 default behaviour. See the installation guide for details. By default,
122 preseeding is confined to setting default values for questions, and Ubiquity
123 will not skip over preseeded steps (this is to allow sensible interpretation
124 of going backward and forward in the UI); if the --automatic option is used,
125 preseeded steps will be skipped.
126 1483
127 The read-only live filesystem should generally be mounted on /rofs.
128 Alternatively, an image may be present as /cdrom/casper/filesystem.cloop,
129 /cdrom/casper/filesystem.squashfs, or (for Guadalinex/Metadistros)
130 1785.1.1 /cdrom/META/META.squashfs. Ubuntu currently uses
131 /cdrom/casper/filesystem.squashfs. You can preseed
132 1601 ubiquity/install/filesystem-images with a space-separated list of image
133 paths to override this; if you provide more than one image, then they will
134 be overlaid using unionfs.
135 1453
136 1785.1.1 /cdrom/casper/filesystem.manifest and
137 /cdrom/casper/filesystem.manifest-desktop should be, respectively, a list of
138 packages in the full live filesystem and a list of packages that should be
139 installed in the target system; the format is that produced by running
140 "dpkg-query -W --showformat='${Package} ${Version}\n'". Ubiquity will remove
141 any packages present in filesystem.manifest but not present in
142 filesystem.manifest-desktop after copying the live filesystem. This allows
143 it to ensure that, for example, Ubiquity itself doesn't end up on the target
144 system.
145
146 1837 Language packs for the selected language are installed by default, using the
147 Ubuntu naming scheme of language-pack-$LL and language-support-$LL. If you
148 want to get rid of these (for example because their dependencies are
149 inconvenient), then you can preseed pkgsel/language-packs to the empty
150 string.
151
152 1770 If /cdrom/.disk/release_notes_url is present, a link to the release notes
153 will be displayed on the language page. Instances of the string ${LANG} in
154 that URL will be replaced with the locale, with any encoding removed (e.g.
155 en, de, pt_BR, zh_CN).
156
157 1785.1.1 If you're installing from a medium other than a CD or DVD (e.g. over NFS),
158 then the path of least resistance is to arrange that something that looks
159 like a CD is available on /cdrom anyway. NFS-mounting an entire CD image is
160 one approach that has worked with relatively little effort, but you could
161 also set up the files listed above in some other way.
162
163 1600 Frequently Asked Questions
164 --------------------------
165
166 Q. Can I backport the version of Ubiquity from the current Ubuntu
167 development release to the previous stable release?
168
169 A. Not without quite a bit of work. At present, Ubiquity is still a complex
170 piece of software with several bleeding-edge dependencies, and at the
171 moment I have no compunctions about making it depend on new packages or
172 newer versions of existing packages in order to get the job done
173 properly. In future, things may settle down such that there can be more
174 compatibility guarantees, particularly if Ubiquity is adopted by other
175 Debian-based distributions.
176
177 At the moment, I can think of the following specific issues with
178 backporting Ubiquity from Ubuntu 6.10 to Ubuntu 6.06:
179
180 * Ubiquity now uses the new Python policy, which involves a number of
181 packaging changes and even a couple of code changes that are
182 incompatible with Ubuntu 6.06. These would need to be reverted.
183
184 * Ubiquity now uses console-setup as the backend for the keyboard
185 screen rather than kbd-chooser. console-setup will not work on Ubuntu
186 6.06, so the kbd-chooser code would need to be resurrected.
187
188 * Ubiquity's GTK frontend now relies on new features in gparted in
189 order to fix some user interface bugs.
190
191 * Ubiquity now integrates with the apport crash reporting facility in
192 Ubuntu 6.10, which is not available in Ubuntu 6.06. (This would just
193 be a matter of removing dependencies; it's optional as far as the
194 code is concerned.)
195
196 * Ubiquity's debconf template translations now rely on new features in
197 po-debconf 1.0, which was not available in Ubuntu 6.06.
198
199 While I'm aware that there were a number of serious issues with the
200 version of Ubiquity that shipped with Ubuntu 6.06 (many of which were
201 corrected in Ubuntu 6.06.1), I feel that the right answer to these is to
202 backport selected fixes to that branch of Ubiquity rather than trying to
203 backport the whole package.
204
205 1785.1.2 Similarly, there are at least the following issues with backporting
206 Ubiquity from Ubuntu 7.04 to Ubuntu 6.10:
207
208 * Ubiquity depends on a version of console-setup at least as new as the
209 one in its own source tree, so the two packages would need to be
210 backported together. The new version of console-setup in turn relies
211 on a newer version of xkb-data (although probably not inextricably).
212
213 * Ubiquity's GTK frontend now uses gtk.LinkButton, which isn't
214 available in the versions of GTK+/PyGTK in Ubuntu 6.10. Similarly,
215 you need a more recent version of glade-3 than is available in Ubuntu
216 6.10 to edit the user interface definition for the GTK frontend.
217
218 1787 * Regenerating Ubiquity's autotools files (configure et al) requires
219 Automake 1.10, not available in Ubuntu 6.10.
220 1785.1.2
221 * Ubiquity's apport crash handler now requires a new Python API
222 introduced in apport 0.33.
223
224 1453
225 2719.1.2 Feel free to ask us (ubuntu-installer@lists.ubuntu.com) if you have any
226 1483 questions regarding Ubiquity's workings.
listensilence 于 2010-03-22 10:16:29发表:
看来楼主用的编辑器是VIM啊！
junyang517 于 2010-03-21 21:11:13发表:
看不懂。。。。。。。。。。。。。
王中云 于 2010-03-21 11:14:09发表:
ubuntu-installer----ubiquity
This is a graphical installer for Ubuntu, written largely in Python, using d-i as a backend for many of its functions. The authors are indebted to the efforts of the Guadalinex project in developing the original "ubuntu-express" code used as a basis for this project.
Background
Around 2000, the debian-installer (later just "d-i") project started to replace the old Debian "boot-floppies" installer. The goals of this project included long-term maintainability, modularity, and code reuse. After a hiatus during the Debian 3.0 release, this project matured into a usable installer in 2004 in time for, among others, the releases of Debian 3.1 and Ubuntu 4.10. From Ubuntu 4.10 to Ubuntu 5.10, d-i was used as the primary installation program. d-i continues to provide flexibility and (for a certain significant class of users) ease of use that a simplified graphical installer will always be hard-pushed to provide. It is therefore important to continue to support it
23 in Ubuntu. From a maintainability point of view, it follows that it is
24 important for any graphical installer supported by Ubuntu to share
25 substantial amounts of code with d-i, particularly where the backend logic
26 is intrinsically difficult and has accumulated large quantities of expertise
27 and bug fixes. Accordingly, Ubiquity is designed to use logic from d-i where
28 possible, and tries to confine itself to being a high-quality frontend.
29
30 (Of course, there remain some areas where d-i does not provide suitable
31 logic, or where its logic has not proven amenable to direct use within
32 Ubiquity, so there is still some backend-style logic and code duplication
33 in Ubiquity. Eventually, as much of this as possible should go away.)
34
35 UI Design
36 ---------
37
38 The primary focus of Ubiquity's UI is ease of use for new users.
39 Accordingly, it does not try to provide all possible options, deferring
40 advanced installation scenarios to d-i so that it does not have to be all
41 things to all people. See http://wiki.ubuntu.com/UbuntuExpress for the
42 original details of its user interface design.
43
44 Debconf Integration
45 -------------------
46
47 The most challenging part of Ubiquity to understand is undoubtedly its
48 integration with d-i. Before getting to grips with this, I assume that the
49 reader has a basic developer-level grasp of the "debconf" configuration
50 system. Reading the debconf-devel(7) man page is a good idea.
51
52 d-i uses debconf for all user interaction. The extant graphical debconf
53 frontends are functional, but crude from a human interface design
54 perspective; although this could be improved, the problem is to some extent
55 intrinsic because they must generate a user interface based on the questions
56 asked by the confmodule. It is possible to do much better using custom user
57 interface code. However, at present debconf has no support for doing this
58 directly (although cdebconf does).
59
60 To deal with this, Ubiquity uses the noninteractive debconf frontend, and
61 instead uses a layer called the "debconffilter". This sits between d-i code
62 and the debconf frontend, intercepting the debconf protocol, and transforms
63 relevant debconf protocol messages into events which can be handled in much
64 the same way as UI events from widget libraries like GTK+ or Qt. While this
65 requires insider knowledge of the questions which may be asked by each piece
66 of d-i code, which must often be updated as d-i evolves, it seems to be the
67 most practical approach at present.
68
69 Each piece of d-i code used in Ubiquity is accompanied by a "component",
70 written in Python, which defines the backend code to be called and any
71 necessary event handlers. To allow for multiple frontend implementations, it
72 typically calls methods in the frontend when UI operations are needed.
73
74 It is important to remember that each call to component event handlers is
75 blocking (though non-reentrant). If UI interaction is required in order to
76 provide an answer to debconf, this must be handled by calling into suitable
77 frontend functions from the component to wait for the user. The component is
78 responsible for maintaining its own state machine if necessary.
79
80 Partitioning
81 ------------
82
83 2037 All partitioning is handled by d-i code (partman), with a presentation layer
84 on top. The presentation layer navigates partman's menus under the hood to
85 perform advanced partitioning. See
86 http://wiki.ubuntu.com/Ubiquity/AdvancedPartitionerRewrite for details.
87
88 A graphical disk view has yet to be written for the GTK frontend's advanced
89 partitioner.
90 1483
91 Installation
92 ------------
93
94 The actual installation takes place by copying the read-only part of the
95 live filesystem. The writable part of the live filesystem (i.e. the running
96 live session) is intentionally not copied, to ensure maximum reproducibility
97 of the installed system. Thus, any customisations applied by the live boot
98 process must be re-applied after the read-only filesystem is copied. The
99 live boot process is responsible for installing hooks in
100 /usr/lib/ubiquity/target-config/ to take care of this.
101
102 After copying the live filesystem, certain unnecessary packages (such as
103 Ubiquity itself) will be removed. The set of packages to be removed is
104 computed by taking those packages present in
105 /cdrom/casper/filesystem.manifest but not present in
106 /cdrom/casper/filesystem.manifest-desktop, and removing any packages
107 explicitly requested for installation by installer code. Language packs for
108 languages which are not to be supported on the installed system will also be
109 removed.
110
111 1500 Logs of the installation will be saved in /var/log/syslog (for messages
112 emitted by Ubiquity itself and messages emitted by d-i code), and
113 /var/log/partman (for a trace of the operation of the automatic
114 partitioner). /var/log/syslog and /var/log/partman are saved in
115 /var/log/installer/ on the installed system.
116 1483
117 Customisation
118 -------------
119
120 Where d-i code is used, it is generally possible to preseed it to change
121 2719.1.1 default behaviour. See the installation guide for details. By default,
122 preseeding is confined to setting default values for questions, and Ubiquity
123 will not skip over preseeded steps (this is to allow sensible interpretation
124 of going backward and forward in the UI); if the --automatic option is used,
125 preseeded steps will be skipped.
126 1483
127 The read-only live filesystem should generally be mounted on /rofs.
128 Alternatively, an image may be present as /cdrom/casper/filesystem.cloop,
129 /cdrom/casper/filesystem.squashfs, or (for Guadalinex/Metadistros)
130 1785.1.1 /cdrom/META/META.squashfs. Ubuntu currently uses
131 /cdrom/casper/filesystem.squashfs. You can preseed
132 1601 ubiquity/install/filesystem-images with a space-separated list of image
133 paths to override this; if you provide more than one image, then they will
134 be overlaid using unionfs.
135 1453
136 1785.1.1 /cdrom/casper/filesystem.manifest and
137 /cdrom/casper/filesystem.manifest-desktop should be, respectively, a list of
138 packages in the full live filesystem and a list of packages that should be
139 installed in the target system; the format is that produced by running
140 "dpkg-query -W --showformat='${Package} ${Version}\n'". Ubiquity will remove
141 any packages present in filesystem.manifest but not present in
142 filesystem.manifest-desktop after copying the live filesystem. This allows
143 it to ensure that, for example, Ubiquity itself doesn't end up on the target
144 system.
145
146 1837 Language packs for the selected language are installed by default, using the
147 Ubuntu naming scheme of language-pack-$LL and language-support-$LL. If you
148 want to get rid of these (for example because their dependencies are
149 inconvenient), then you can preseed pkgsel/language-packs to the empty
150 string.
151
152 1770 If /cdrom/.disk/release_notes_url is present, a link to the release notes
153 will be displayed on the language page. Instances of the string ${LANG} in
154 that URL will be replaced with the locale, with any encoding removed (e.g.
155 en, de, pt_BR, zh_CN).
156
157 1785.1.1 If you're installing from a medium other than a CD or DVD (e.g. over NFS),
158 then the path of least resistance is to arrange that something that looks
159 like a CD is available on /cdrom anyway. NFS-mounting an entire CD image is
160 one approach that has worked with relatively little effort, but you could
161 also set up the files listed above in some other way.
162
163 1600 Frequently Asked Questions
164 --------------------------
165
166 Q. Can I backport the version of Ubiquity from the current Ubuntu
167 development release to the previous stable release?
168
169 A. Not without quite a bit of work. At present, Ubiquity is still a complex
170 piece of software with several bleeding-edge dependencies, and at the
171 moment I have no compunctions about making it depend on new packages or
172 newer versions of existing packages in order to get the job done
173 properly. In future, things may settle down such that there can be more
174 compatibility guarantees, particularly if Ubiquity is adopted by other
175 Debian-based distributions.
176
177 At the moment, I can think of the following specific issues with
178 backporting Ubiquity from Ubuntu 6.10 to Ubuntu 6.06:
179
180 * Ubiquity now uses the new Python policy, which involves a number of
181 packaging changes and even a couple of code changes that are
182 incompatible with Ubuntu 6.06. These would need to be reverted.
183
184 * Ubiquity now uses console-setup as the backend for the keyboard
185 screen rather than kbd-chooser. console-setup will not work on Ubuntu
186 6.06, so the kbd-chooser code would need to be resurrected.
187
188 * Ubiquity's GTK frontend now relies on new features in gparted in
189 order to fix some user interface bugs.
190
191 * Ubiquity now integrates with the apport crash reporting facility in
192 Ubuntu 6.10, which is not available in Ubuntu 6.06. (This would just
193 be a matter of removing dependencies; it's optional as far as the
194 code is concerned.)
195
196 * Ubiquity's debconf template translations now rely on new features in
197 po-debconf 1.0, which was not available in Ubuntu 6.06.
198
199 While I'm aware that there were a number of serious issues with the
200 version of Ubiquity that shipped with Ubuntu 6.06 (many of which were
201 corrected in Ubuntu 6.06.1), I feel that the right answer to these is to
202 backport selected fixes to that branch of Ubiquity rather than trying to
203 backport the whole package.
204
205 1785.1.2 Similarly, there are at least the following issues with backporting
206 Ubiquity from Ubuntu 7.04 to Ubuntu 6.10:
207
208 * Ubiquity depends on a version of console-setup at least as new as the
209 one in its own source tree, so the two packages would need to be
210 backported together. The new version of console-setup in turn relies
211 on a newer version of xkb-data (although probably not inextricably).
212
213 * Ubiquity's GTK frontend now uses gtk.LinkButton, which isn't
214 available in the versions of GTK+/PyGTK in Ubuntu 6.10. Similarly,
215 you need a more recent version of glade-3 than is available in Ubuntu
216 6.10 to edit the user interface definition for the GTK frontend.
217
218 1787 * Regenerating Ubiquity's autotools files (configure et al) requires
219 Automake 1.10, not available in Ubuntu 6.10.
220 1785.1.2
221 * Ubiquity's apport crash handler now requires a new Python API
222 introduced in apport 0.33.
223
224 1453
225 2719.1.2 Feel free to ask us (ubuntu-installer@lists.ubuntu.com) if you have any
226 1483 questions regarding Ubiquity's workings.
junyang517 于 2010-03-21 10:29:44发表:
看不懂啊。。。。。。。。。。。
xzj4167 于 2010-03-21 06:48:24发表:
命令行安装行不行？