← Back to branch summary

~ubuntu-branches/ubuntu/saucy/live-manual/saucy-proposed

« back to all changes in this revision

Viewing changes to manual/pt_BR/user_managing_a_configuration.ssi

  • Committer: Package Import Robot
  • Author(s): Daniel Baumann, Ben Armstrong, chals, Daniel Baumann
  • Date: 2012-08-10 22:48:06 UTC
  • mfrom: (29.2.6 sid)
  • Revision ID: package-import@ubuntu.com-20120810224806-i4vzvy1ijmtt32va
Tags: 1:3.0~a15-1
[ Ben Armstrong ]
* Renaming keyboard-variant to keyboard-variants, matching latest
  live-config.

[ chals ]
* Updating Spanish and French translations to keyboard-variants.

[ Ben Armstrong ]
* Beginning change from predefined package lists to metapackages.

[ chals ]
* Updating Spanish translation of user_customization-packages.ssi.po.

[ Daniel Baumann ]
* Updating the internal list of strings that get automatically a
  certain markup (like debian release codenames, debian packages
  names, etc.).

[ chals ]
* Insisting on the fact that achieving a 100% translation is important
  in respect to code blocks.
* Updating French translation of user_customization.ssi.po, after the
  addition of metapackages.
* Updating Catalan translation of user_customization-packages.ssi.po,
  after the addition of metapackages.

[ Ben Armstrong ]
* Updating apt pinning example to correct actual metapackage
  dependencies.
* Rewriting introductory package list sections around metapackages
  instead of predefined lists.

[ chals ]
* Updating translation of es/user_customization-packages.ssi (apt
  pinning).
* Updating translation of fr/user_customization-packages.ssi (apt
  pinning).
* Updating the translation of ca/user_customization-packages.ssi (apt
  pinning).
* Fixing mismatch in the indexes of the Spanish and French manuals.

[ Ben Armstrong ]
* Explaining multiple lists, dropping includes and tasks, adding
  generated lists.
* Fixing minor typo in Packages helper paragraph.

[ chals ]
* Updating Spanish translation of user_customization-packages
  (multiple lists).
* Updating French translation of user_customization-packages (multiple
  lists).
* Updating Catalan translation of user_customization-packages
  (multiple lists).
* Translating user_customization-runtime.ssi.po into Catalan.
* Revising the now unsupported '-p|--package-lists' option providing
  alternatives, thanks to Ben Armstrong for the hints.
* Copying minimal.chroot hook to config/hooks and thus making the
  example work.
* Removing 'standard-x11 list' and explaining the lists a bit better.
* Removing '--includes none' from the minimal image example as it is
  unsupported and was tested without that option.
* Providing a way to create a smaller image before the size
  optimization warning in the examples.
* Proofreading project_bugs.
* Removing the binary includes section since they were dropped.

[ Ben Armstrong ]
* Rewriting 'Managing a configuration' for greater clarity and
  introducing --config option.

[ chals ]
* Running 'make commit' to avoid conflicts and thus being able to
  commit languages individually afterwards; there are too many changes
  to cope with them all.

[ Ben Armstrong ]
* Fixing lb config --config examples: missing option.

[ chals ]
* Updating Catalan translation of user_managing a configuration, lb
  config --config.

[ Ben Armstrong ]
* Clarifying section headings relating to auto scripts.

[ chals ]
* Removing 'echo' to improve readability.
* Updating Catalan translation of the headings of auto scritps.
* Starting work to complete the Spanish translation, adding missing
  code blocks and updating user_customization-contents, project_bugs
  and user_overview.
* Starting work to complete the French translation, adding missing
  code blocks and updating user_customization-contents,
  user_customization-packages and user_overview.
* Revising the French translation of project_bugs and fixing its
  'fuzzy' string.
* Completing the French translation with user_examples and
  user_managing_a_configuration and revising po headers.
* Revising the headers in the Spanish po files that showed 'Catalan'
  by an error.

[ Ben Armstrong ]
* Updating prerequisites: Linux 3.x included.
* Updating build live-boot and live-config from source to reflect best
  practice for short-term testing.
* Clarifying example uses bash commands.

[ chals ]
* Completing the Spanish translation with
  user_managing_a_configuration, user_installation and user_examples.
* Updating French translation of user_installation.
* Updating the Catalan translation of user_installation.ssi.po.
* Fixing one title in the Spanish translation and improving one string
  in user_installation.ssi.po.

[ Ben Armstrong ]
* Clarifying --apt-recommends false has consequences for live-*
  packages.
* Updating language tasks section and examples chapter to no longer
  use task lists.

[ chals ]
* Re-adding packages left out by 'apt-recommends false' to make the
  images work properly in the examples.

Show diffs side-by-side

added added

removed removed

Lines of Context:
manual/pt_BR/user_managing_a_configuration.ssi
6
6
creation, through successive revisions and successive releases of both the
7
7
live-build software and the live image itself.
8
8
 
9
 
2~ Use auto to manage configuration changes
10
 
 
11
 
Live configurations rarely are perfect on the first try. You'll likely need
12
 
to make a series of revisions until you are satisfied. However,
13
 
inconsistencies can creep into your configuration from one revision to the
14
 
next if you aren't careful. The main problem is, once a variable is given a
15
 
default value, that value will not be recomputed from other variables that
16
 
may change in later revisions.
17
 
 
18
 
For example, when the distribution is first set, many 'dependent' variables
19
 
are given default values that suit that distribution. However, if you later
20
 
decide to change the distribution, those dependent variables continue to
21
 
retain old values that are no longer appropriate.
22
 
 
23
 
A second, related problem is that if you run #{lb config}# and then upgrade
24
 
to a new version of live-build that has changed one of the variable names,
25
 
you will discover this only by manual review of the variables in your
26
 
#{config/*}# files, which you will then need to use to set the appropriate
27
 
option again.
28
 
 
29
 
All of this would be a terrible nuisance if it weren't for auto/* scripts,
30
 
simple wrappers to the #{lb config}#, #{lb build}# and #{lb clean}# commands
31
 
that are designed to help you manage your configuration. Simply create an
32
 
auto/config script containing #{lb config}# command with all desired
33
 
options, and an auto/clean that removes the files containing configuration
34
 
variable values, and each time you run #{lb config}# and #{lb clean}#, these
35
 
files will be executed. This will ensure that your configuration is kept
36
 
internally consistent from one revision to the next and from one live-build
37
 
release to the next (Although you will still have to take care and read the
38
 
documentation when you upgrade live-build and make adjustments as needed).
39
 
 
40
 
2~ Example auto scripts
41
 
 
42
 
Use auto script examples such as the following as the starting point for
43
 
your new live-build configuration. Take note that when you call the #{lb}#
44
 
command that the auto script wraps, you must specify #{noauto}# as its
45
 
parameter to ensure that the auto script isn't called again,
46
 
recursively. Also, don't forget to ensure the scripts are executable
47
 
(e.g. #{chmod 755 auto/*}#).
48
 
 
49
 
#{auto/config}#
 
9
2~ Dealing with configuration changes
 
10
 
 
11
Live configurations rarely are perfect on the first try. It may be fine to
 
12
pass #{lb config}# options from the command-line to perform a single build,
 
13
but it is more typical to revise those options and build again until you are
 
14
satisfied. To support these changes, you will need auto scripts which ensure
 
15
your configuration is kept in a consistent state.
 
16
 
 
17
3~ Why use auto scripts? What do they do?
 
18
 
 
19
The #{lb config}# command stores the options you pass to it in #{config/*}#
 
20
files along with many other options set to default values. If you run #{lb
 
21
config}# again, it will not reset any option that was defaulted based on
 
22
your initial options. So, for example, if you run #{lb config}# again with a
 
23
new value for #{--distribution}#, any dependent options that were defaulted
 
24
for the old distribution may no longer work with the new. Nor are these
 
25
files intended to be read or edited. They store values for over a hundred
 
26
options, so nobody, let alone yourself, will be able to see in these which
 
27
options you actually specified. And finally, if you run #{lb config}#, then
 
28
upgrade live-build and it happens to rename an option, #{config/*}# would
 
29
still contain variables named after the old option that are no longer valid.
 
30
 
 
31
For all these reasons, #{auto/*}# scripts will make your life easier. They
 
32
are simple wrappers to the #{lb config}#, #{lb build}# and #{lb clean}#
 
33
commands that are designed to help you manage your configuration. The
 
34
#{auto/config}# script stores your #{lb config}# command with all desired
 
35
options, the #{auto/clean}# script removes the files containing
 
36
configuration variable values, and the #{auto/build}# script keeps a
 
37
#{build.log}# of each build. Each of these scripts is run automatically
 
38
every time you run the corresponding #{lb}# command. By using these scripts,
 
39
your configuration is easier to read and is kept internally consistent from
 
40
one revision to the next. Also, it will be much easier for you identify and
 
41
fix options which need to change when you upgrade live-build after reading
 
42
the updated documentation.
 
43
 
 
44
3~ Use example auto scripts
 
45
 
 
46
For your convenience, live-build comes with example auto shell scripts to
 
47
copy and edit. Start a new, default configuration, then copy the examples
 
48
into it:
 
49
 
 
50
code{
 
51
 
 
52
 $ mkdir mylive && cd mylive && lb config
 
53
 $ cp /usr/share/doc/live-build/examples/auto/* auto/
 
54
 
 
55
}code
 
56
 
 
57
Edit #{auto/config}#, adding any options as you see fit. For instance:
50
58
 
51
59
code{
52
60
 
53
61
 #!/bin/sh
54
62
 lb config noauto \
55
 
     --package-lists "standard" \
 
63
     --architectures i386 \
 
64
     --linux-flavours 686-pae \
 
65
     --binary-images hdd \
 
66
     --mirror-bootstrap http://ftp.es.debian.org/debian/ \
 
67
     --mirror-binary http://ftp.es.debian.org/debian/ \
56
68
     "${@}"
57
69
 
58
70
}code
59
71
 
60
 
#{auto/clean}#
61
 
 
62
 
code{
63
 
 
64
 
 #!/bin/sh
65
 
 lb clean noauto "${@}"
66
 
 rm -f config/binary config/bootstrap \
67
 
     config/chroot config/common config/source
68
 
 rm -f build.log
69
 
 
70
 
}code
71
 
 
72
 
#{auto/build}#
73
 
 
74
 
code{
75
 
 
76
 
 #!/bin/sh
77
 
 lb build noauto "${@}" 2>&1 | tee build.log
78
 
 
79
 
}code
80
 
 
81
 
We now ship example auto scripts with live-build based on the examples
82
 
above. You may copy those as your starting point.
83
 
 
84
 
code{
85
 
 
86
 
 $ cp /usr/share/doc/live-build/examples/auto/* auto/
87
 
 
88
 
}code
89
 
 
90
 
Edit #{auto/config}#, changing or adding any options as you see fit. In the
91
 
example above, #{--package-lists standard}# is set to the default
92
 
value. Change this to an appropriate value for your image (or delete it if
93
 
you want to use the default) and add any additional options in continuation
94
 
lines that follow.
 
72
Now, each time you use #{lb config}#, #{auto/config}# will reset the
 
73
configuration based on these options. When you want to make changes to them,
 
74
edit the options in this file instead of passing them to #{lb config}#. When
 
75
you use #{lb clean}#, #{auto/clean}# will clean up the #{config/*}# files
 
76
along with any other build products. And finally, when you use #{lb build}#,
 
77
a log of the build will be written by #{auto/build}# in #{build.log}#.
 
78
 
 
79
Note: A special #{noauto}# parameter is used here to suppress another call
 
80
to #{auto/config}#, thereby preventing infinite recursion. Make sure you
 
81
don't accidentally remove it when making edits. Also, take care to ensure
 
82
when you split the #{lb config}# command across multiple lines for
 
83
readability, as shown in the example above, that you don't forget the
 
84
backslash (\) at the end of each line that continues to the next.
 
85
 
 
86
2~ Clone a configuration published via Git
 
87
 
 
88
Use the #{lb config --config}# option to clone a Git repository that
 
89
contains a Debian Live configuration. If you would like to base your
 
90
configuration on one maintained by the Debian Live project, look at
 
91
http://live.debian.net/gitweb for the repositories prefixed with
 
92
#{config-}#.
 
93
 
 
94
For example, to build a rescue image, use the #{config-rescue}# repository
 
95
as follows:
 
96
 
 
97
code{
 
98
 
 
99
 $ mkdir live-rescue && cd live-rescue
 
100
 $ lb config --config git://live.debian.net/git/config-rescue.git
 
101
 
 
102
}code
 
103
 
 
104
Edit #{auto/config}# and any other things you need in the #{config}# tree to
 
105
suit your needs.
 
106
 
 
107
You may optionally define a shortcut in your Git configuration by adding the
 
108
following to your #{${HOME}/.gitconfig}#:
 
109
 
 
110
code{
 
111
 
 
112
 [url "git://live.debian.net/git/"]
 
113
     insteadOf = ldn:
 
114
 
 
115
}code
 
116
 
 
117
This enables you to use #{ldn:}# anywhere you need to specify the address of
 
118
a #{live.debian.net}# git repository. If you also drop the optional #{.git}#
 
119
suffix, starting a new image using this configuration is as easy as:
 
120
 
 
121
code{
 
122
 
 
123
 $ lb config --config ldn:config-rescue
 
124
 
 
125
}code
 
126