Differences between revisions 30 and 31
Revision 30 as of 2016-08-14 14:54:18
Size: 6316
Editor: GuillemJover
Comment: Add more perl implementations
Revision 31 as of 2016-08-14 15:02:47
Size: 6360
Editor: GuillemJover
Comment: Add yet another perl implementation
Deletions are marked like this. Additions are marked like this.
Line 78: Line 78:
   * DebianPkg:libdebian-package-html-perl

Dpkg Roadmap

Before starting work on any of this and to avoid duplication, please get in contact with us on the mailing list, as someone might have already started, or there might be initial code around in the personal git repositories or local trees.

The 1.18.x development series

  • Optimization work.

    • Faster and smaller!
  • Package building infrastructure fixes:
    • Updates for the format of .changes files. 138409, 65699. The latter is less likely if we switch to rebuild on all architectures (and hence scratch the maintainer uploaded .deb).

  • New dpkg shared library:

    • Library API cleanup and general code refactoring.
    • Provide pluggable allocators to avoid leaking through nfmalloc (code in pu/new-mem-pool).
    • No printing from the library for non-fatal errors, will have to change to return error codes.
    • Try to make as much as possible reentrant.
    • Refactor .deb generation.

    • New libdpkg0 and libdpkg0-dbg packages (code in pu/libdpkg).
  • Merge back apt's apt-deb/deb/ and apt-inst/deb/:
    • Provide a public interface to access .deb files (Depends: #libdpkg).

    • Switch apt to use libdpkg (Depends: #refactor-deb).

  • Merge back debconf support:
    • Merge back apt-exttracttemplates (Depends: #refactor-deb).

    • Finish to draft the spec for the debconf integration (?DpkgDebconfIntegration):

      • (!) Implement --reconfigure??

        • dpkg --reconfigure <pkg> <pkg>

        • <pkg>.postinst reconfigure <ver>

        • Fail if pkg is not in the configured state.
  • Extend conffile support, merge back ucf:
    • Store conffiles at install time (?Teams/Dpkg/Proposals/ConffileDatabase).

    • Support registering configuration files.
    • Add a new dpkg-conffile to handle conffiles (view, diff, rm, restore, etc).
  • Merge back debsums:
    • Generate checksums at build time?
    • Store metadata from .deb at install time.
    • Add a new dpkg-foo to verify, restore, etc metadata.
  • Merge back localepurge:
    • Now after support for --path-exclude/--path-include, localepurge can be considered obsolete or just a way to provide config files.
  • Merge back dlocate:
    • Speed up file searches «dpkg-query -S» (Depends: #optimize).

  • Merge back functionality from dpkg-sig, debsigs-verify, etc:
    • Draft a new spec for the signature support inside .deb, discussion started on the mailing list.
    • Write a dpkg-sig (or similarly named program) in C (Depends: #refactor-deb).

    • The archive should allow signed packages. Tracked in 340306

  • Merge back functionality from perl implementations:
  • Translation deb support:

    • Clarify the draft (had some discussions about that with the i18n team at DebConf).

    • Depending on the discussions might need either #refactor-deb or filters (implemented), or other stuff.

  • Clean up dpkg namespace:
    • Eventual move of the method directories to /usr/lib/dselect/.
  • Better integration with front-ends:
    • Discuss and decide about dpkg knowledge of repository information. Either push out the available file handling to the front-ends, or take full responsibility of repository package availability.
    • Restore binary package constrained filename field (old MSDOS-Filename) support.
    • Add a way to notify backends that they need to restart themselves, so that packages can use new features w/o waiting for a full release cycle. One of the issues is that even if dpkg is upgraded, the new version might not run for a long while (537051). Possible options:

      • Make frontends check if a package pre-depends on dpkg, and upgrade that first, and continue with the rest as a different transaction.
      • Add metadata so that frontends start a new dpkg transaction, forcing the new program to be executed.
      • Change dpkg to reexec itself on upgrades.
      • Frontends themselves might also need to restart themselves.
    • Include dpkg-checkbuilddeps.
    • Switch to use --update-avail/--merge-avail from stdin/pipe.
    • Bug on cupt to produce pristine available db information (non-humanized).
    • Working --command-fd: https://lists.debian.org/deity/2011/07/msg00119.html.

    • A way for front-ends to store additional information for each package.
    • Unified unseen tracking:
      • dselect unseen tracking.
      • apt/aptitude unseen tracking.
    • Unified holds:
      • aptitude ignores dpkg holds in some cases: 137771

      • dpkg needs to record when package state changed: 429438

      • dpkg needs to remember holds for uninstalled packages: 706770

    • New “Status-Hold-Cond:” db field to track things like aptitude version holds, or other conditionals, value could be «version >> 1.16.7». Or maybe even a more generic handling of conditions regarding status values? Even front-end related ones?

    • Frontends should not use any force option, they should use dpkg “transactions” via selections. There's already ongoing discussions with apt and cupt maintainers.
    • Frontends should not be parsing dpkg error/progress messages, dpkg should provide a reliable way to notify about those.
    • Check if other front-end parts (aptitude, synaptic, wajig, ept, ...) should be pushed down the stack.
    • Other stuff, would need to ask front-end developers.
  • Move back relevant documentation from policy into dpkg.
    • Russ has mentioned this at some points, should discuss with the policy team.