Differences between revisions 6 and 7
Revision 6 as of 2011-04-06 22:52:24
Size: 1666
Editor: ?Sam Dunne
Comment: Adding link to GSoC application
Revision 7 as of 2011-06-01 16:52:11
Size: 1505
Editor: ?Sam Dunne
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:

 * '''Student''': Sam Dunne
Line 4: Line 7:
 * '''Required skills''':
  * C programming
  * ability to communicate clearly in written English
Line 8: Line 9:
 * '''Applications''':
  * [[SummerOfCode2011/DeclarativeDiversions/ChristopherBaines|Christopher Baines]]
  * [[SummerOfCode/Declarative_Diversions/aregee|Rahul Gaur]]
  * [[SummerOfCode2011/DeclarativeDiversions/GillesFernandez|Gilles Fernandez]]
  * [[SummerOfCode2011/DeclarativeDiversions/DanielLobato|Daniel Lobato]]
  * [[SummerOfCode2011/DeclarativeDiversions/SamDunne|Sam Dunne]]

 * '''Challenges''':
  * What syntax do we use for the new control file?
  * How do we handle diversions to a non-existant directory?
  * How do we order unpacking a new package which adds a diversion?
  * How do we order removing a package which had a diversion?
  * How do we handle errors?

Declarative diversions

  • Mentor: Steve Langasek; supported by Raphaël Hertzog for dpkg maintainer review and sign-off

  • Student: Sam Dunne

  • Summary: implement support for declarative diversions in dpkg, to obsolete manual calls to dpkg-divert in maintainer scripts

  • Description: The dpkg package manager allows packages to redirect ("divert") files belonging to one package to replace them with their own implementation. This is currently done by invoking a command, dpkg-divert, from package maintainer scripts, which is fragile and error prone; most references to dpkg-divert in the maintainer scripts of a typical system today are attempts to fix up past incorrect uses of dpkg-divert.
    The dpkg-divert command should be replaced with a new control file with a declarative syntax which dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions.
    Any solution to this problem must include documentation on correct use of the new feature and provide a transition path for packages using the existing non-declarative method of diverting files.

  • Challenges:

    • What syntax do we use for the new control file?
    • How do we handle diversions to a non-existant directory?
    • How do we order unpacking a new package which adds a diversion?
    • How do we order removing a package which had a diversion?
    • How do we handle errors?