home *** CD-ROM | disk | FTP | other *** search
/ PC Welt 2006 November (DVD) / PCWELT_11_2006.ISO / casper / filesystem.squashfs / usr / src / linux-headers-2.6.17-6 / debian / docs / LinkPolicy < prev    next >
Encoding:
Text File  |  2005-06-08  |  9.2 KB  |  204 lines
  1.  
  2.    $Id: LinkPolicy,v 1.4 1998/01/30 01:26:31 srivasta Exp $
  3.  
  4. This is an proposal for packages providing kernel sources, headers,
  5. and image, which attempts to make it possible to have multiple
  6. versions of the kernel headers/source/image on the system
  7. concurrently.
  8.  
  9. It would be nice if removing a current source/header could roll back
  10. to any older versions still on the system, but that seems hard, though
  11. I think I see a way to do this. (Read on for details).
  12.  
  13. The source unpack into /usr/src/linux-X.X.XX, and kernel headers only
  14. package unpacks into /usr/src/headers-X.X.XX (so that the
  15. kernel-source and kernel-header package do not need to conflict at
  16. all). /usr/src/linux is a symlink that is maintained current by the
  17. Debian package scripts, pointing to the most recently installed source
  18. or header. We try to ensure that it will always point somewhere sane.
  19.  
  20. We accommodate multiple versions by having each package include the
  21. kernel version in the name, and provide a corresponding virtual
  22. package.  For example, assuming that a user has kernel versions 1.3.64
  23. and 1.3.95 on her system, we get:
  24.  
  25. Package Name           Package version         provides
  26. ======================================================================
  27. kernel-source-1.3.95    1.3.95-1          kernel-headers, kernel-source
  28. kernel-headers-1.3.95   1.3.95-1          kernel-headers
  29. kernel-image-1.3.95     1.3.95-1          kernel-image
  30.             
  31. kernel-source-1.3.64    1.3.64-3          kernel-headers, kernel-source
  32. kernel-headers-1.3.64   1.3.64-3          kernel-headers
  33. kernel-image-1.3.64     1.3.64-3          kernel-image
  34. ======================================================================
  35.  
  36. The following analysis shows we should have a postinst and postrm for
  37. both headers and source. The image has a postinst, to ask if the user
  38. wants to run LILO. 
  39.  
  40. ======================================================================
  41. Case A:
  42.   upgrade source/header X to source/header Y
  43.   script            action      version on disk
  44.   X prerm                           X
  45.   Y preinst                         X
  46.                  unpack         X
  47.   X postrm upgrade                  X           no change
  48.                      remove         X
  49.   Y postinst                        X           (no harm, if re-links) (a)
  50. ----------------------------------------------------------------------
  51. Case B:
  52.   Install source/header Y along with  header/source X
  53.   Y preinst                         X
  54.              unpack                 X,Y
  55.   Y postinst                        X,Y          <---- change link      (b) 
  56. ----------------------------------------------------------------------  
  57. Case C:
  58.     remove current source/header X no other source/header exists
  59.   X prerm                           X
  60.                      remove         X'
  61.   X postrm   remove                 X'            <---- remove link        (c)
  62.   X postrm   purge                  X'            no harm in removing link (d)
  63. ----------------------------------------------------------------------
  64. Case D:
  65.     remove current source/header X (some version exists)
  66.   X prerm                           X,Y
  67.                      remove        X',Y
  68.   X postrm   remove                X',Y           <---- relink to Y        (f)
  69.   X postrm   purge                 X',Y           <- ignore, or relink to Y(g)
  70. ----------------------------------------------------------------------
  71. Case E:
  72.     remove non-current source/header X 
  73.   X prerm                           X,Y
  74.                      remove        X',Y
  75.   X postrm   remove                X',Y           ignore link != X         (h)
  76.   X postrm   purge                 X',Y           <- ignore                (i)
  77. ======================================================================
  78.  
  79. X' is the case when X should be gone, but isn't really since directory
  80. isn't empty (compiling kernels leaves .depends and other files all
  81. over the place, so the directory isn't empty when dpkg removes all the
  82. files listed for that directory).
  83.  
  84. The problem in handling cases c/d and e/f is that if no other source
  85. or header packages are available, then /usr/src/linux should be
  86. removed, or else it should be rolled back to a previously installed
  87. version.  The hard part is to distinguish between the two cases, and
  88. to discover which is a valid directory to link to. Just searching in
  89. /usr/src is not good enough, because of the possible dreck left by
  90. unclean source directories.
  91.  
  92. Maybe I should maintain a list of current valid directory names,
  93. updated by postinst like so:
  94.   (echo headers-X.X.XX >> .versionlist)
  95. and removed in postrm like so:
  96.   (cp .versionlist .save$$; grep -v headers-X.X.XX .save$$ > .versionlist)
  97. where .version list is a conffile. last -1 .versionlist will give the
  98. next candidate.
  99.  
  100.  
  101. ======================================================================
  102. postrm called with argument:
  103. abort-upgrade               -- ignore, no preinst to unwind from
  104. abort-install               -- ignore, no preinst to unwind from   
  105. abort-install               -- ignore, no preinst to unwind from
  106. upgrade <newversion>        -- ignore, same directory
  107. failed-upgrade <oldversion> -- ignore, we didn't change anything in upgrade
  108. disappear                   -- ignore, we are safe, no conflict
  109. remove                      -- ignore unless builtin version is the same as
  110.                                link target, or do last .versionlist; relink
  111.                                to version found or remove link if none
  112. purge                       -- ignore, proper action taken in remove
  113.  
  114. postinst called with argument:
  115. abort-upgrade              -- ignore, no prerm to unwind from
  116. failed-upgrade             -- ignore, since we ignore abort-upgrade
  117. abort-deconfigure          -- ignore, no prerm to unwind from
  118. abort-remove               -- ignore, no prerm to unwind from
  119. abort-upgrade new-version    -- ignore, we didn't change anything in upgrade
  120. configure                    -- link to builtin version
  121. ======================================================================
  122.  
  123.  
  124.     The following is an message on posted on the debian mailing
  125.  lists that provides a rationale for the link policy defined in this
  126.  document. 
  127.  
  128. ______________________________________________________________________
  129.  
  130.  
  131.  
  132. >>"Noel" == Noel Maddy <ncm@biostat.hfh.edu> writes:
  133.  
  134. Noel> It still leaves me with one question, though.  If the kernel
  135. Noel> headers that Debian is supplying for libc6 compilation are
  136. Noel> needed only for libc6 compilation, why are they kept in /usr/src
  137. Noel> with a symlink rather than putting them directly in
  138. Noel> /usr/include/linux?
  139.  
  140.  
  141.     Well, this kinda belongs to the can of worms we fondly
  142.  remember as "Debian's /usr/src policy" ;-). Lets see if I can address
  143.  this. Firstly, kernel headers are not merely for libc6
  144.  compilation. In fact, /usr/src/linux is not referenced at all by
  145.  normal compilation processes: those depend, in particular, on the
  146.  symbolic link /usr/src/linux-2.0.32, which is provided by either
  147.  kernel-headers-2.0.32 or by kernel-source-2.0.32.
  148.  
  149.  
  150.  /usr/src/linux           is meant to be a link to the chronologically
  151.                           latest installed set of kernel headers
  152.  /usr/src/linux-X.X.XX    is meant to be a link to a specific version
  153.                           of kernel include files.
  154.  
  155. Noel> I would think that having kernel-headers put them directly into
  156. Noel> /usr/include/linux would make more sense.  That probably means
  157. Noel> that I'm not understanding some of the issues...
  158.  
  159.     Then that means you could not have more than one kernel
  160.  headers or source packages installed. I have, at the moment, 2
  161.  header packages and 4 source packages on my machine. If they all
  162.  tried to go into /usr/src/linux; that would be chaos. Espescially if
  163.  /usr/src/linux were merely overlaid with the most recent install
  164.  (imagine installing 2.0.34 over 2.1.82 -- what a mess)
  165.  
  166.     It is easy to manipulate the symbolic link in the
  167.  postrm/postinst phases of package management.
  168.  
  169.     Why ahve them there at all? It is for the convenience of
  170.  module writes, honest ;-)
  171.  
  172.     If I am a developer who has lovingly crafted, say, a kernel
  173.  module inextricably linked to a particular kernel version (and I
  174.  happen to know it does not work with older kernels, and may not work
  175.  with newer ones), I would put -I/usr/src/linux-Y.Y.YY, for the
  176.  relevant Y.Y.YY version of the kernel. The user may then install the
  177.  whole kernel source, or just the headers, and my module shall
  178.  compile. 
  179.  
  180.     If, on the other hand, I am creating a module that say,
  181.  reports details on kernel internals, based on a set of definitions
  182.  based in a kernel header file, which may change from kernel to kernel
  183.  but has a fixed API, I can get a version tailored to the latest
  184.  kernel version by just specifying: -I/usr/src/linux, and be satisfied
  185.  that I can load a kernel header or source package, and recompile my
  186.  code, and it shall pick up the latest set of headers.
  187.  
  188.     In either case I may have to put code into the module to test
  189.  the running kernel if required ;-)
  190.  
  191.     That is the rationale behind the set of symlinks
  192.  /usr/src/linux* on a Debian system (remember, actual headers and
  193.  sources reside in /usr/src/kernel-{header,source}-Y.Y.YY).
  194.  
  195.     I hope this clarifies things a trifle.
  196.  
  197.     manoj
  198. Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
  199. Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
  200.  
  201.  
  202.  
  203.  
  204.