1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Package Structure</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos User Guide"
20 HREF="ecos-user-guide.html"><LINK
22 TITLE="Managing the Package Repository"
23 HREF="managing-package-repository.html"><LINK
25 TITLE="Managing the Package Repository"
26 HREF="managing-package-repository.html"><LINK
29 HREF="appendices.html"></HEAD
40 SUMMARY="Header navigation table"
57 HREF="managing-package-repository.html"
65 >Chapter 29. Managing the Package Repository</TD
71 HREF="appendices.html"
85 NAME="PACKAGE-STRUCTURE">Package Structure</H1
87 >The files in an installed <SPAN
90 > source tree are organized in
91 a natural tree structure, grouping together files which work together
98 >. For example, the kernel files
99 are all together in: </P
117 ><version></I
134 ><version></I
151 ><version></I
161 >and µITRON compatibility layer files are in:
180 ><version></I
197 ><version></I
214 ><version></I
224 >The feature of these names which is of interest here is
228 ><version></I
230 > near the end. It may seem odd to place a version number deep in the
231 path, rather than having something like
242 ><version></I
244 >/...everything...</TT
246 or leaving it up to you to choose a different
247 install-place when a new release of the system arrives.
250 >There is a rationale for this organization: as
251 indicated, the kernel and the
252 µITRON compatibility subsystem
253 are examples of software packages. For the first few
257 >, all the packages will move along
258 in step, i.e. Release 1.3.x will feature Version
259 1.3.x of every package, and so forth. But in future,
260 especially when third party packages become available, it is
261 intended that the package be the unit of software
262 distribution, so it will be possible to build a system from
263 a selection of packages with different version numbers, and
264 even differing versioning <SPAN
275 provided in the <SPAN
278 > repository to manage the installation
279 and removal of packages in this way.</P
281 >Many users will have their own source code control system,
282 version control system or equivalent, and will want to use it with
286 > sources. In that case, since a new release of <SPAN
290 different pathnames for all the source files, a bit of work is necessary
291 to import a new release into your source repository. </P
293 >One way of handling the import is to rename all the version
294 parts to some common name, for example “current”,
295 and continue to work. “current” is suggested because <B
299 it and places it first in any list of versions. In the future, we
300 may provide a tool to help with this, or an option in the install
301 wizard. Alternatively, in a POSIX shell environment (Linux or Cygwin
302 on Windows) use the following command: </P
314 ><version></I
316 > -type d -printf 'mv %p %h/current\n' | sh</PRE
321 >Having carried out such a renaming operation, your
322 source tree will now look like this: </P
336 >/kernel/current/include/
342 >/kernel/current/src/
348 >/kernel/current/tests/
355 >/compat/uitron/current/include/
361 >/compat/uitron/current/src/
367 >/compat/uitron/current/tests/
373 >which is a suitable format for import into your own
374 source code control system. When you get a subsequent
378 >, do the same thing and use your own source
379 code control system to manage the new source base, by
380 importing the new version from </P
394 >/kernel/current/include/</PRE
404 > build tool will now offer only the
405 “current” version of each package; select this
406 for the packages you wish to use. </P
408 >Making such a change has implications for any build
409 trees you already have in use. A configured build tree
410 contains information about the selected packages and their
411 selected versions. Changing the name of the
412 “versioning” folder in the source tree
413 invalidates this information, and in consequence it also
414 invalidates any local configuration options you have set up
415 in this build tree. So if you want to change the version
416 information in the source tree, do it first, before
417 investing any serious time in configuring and building your
418 system. When you create a new build tree to deal with the
419 new source layout, it will contain default settings for all
420 the configuration options, just like the old build tree did
421 before you configured it. You will need to redo that
422 configuration work in the new tree. </P
424 >Moving source code around also invalidates debugging information
425 in any programs or libraries built from the old tree; these will
426 need to be rebuilt. </P
433 SUMMARY="Footer navigation table"
444 HREF="managing-package-repository.html"
453 HREF="ecos-user-guide.html"
462 HREF="appendices.html"
472 >Managing the Package Repository</TD
478 HREF="managing-package-repository.html"