Differences between revisions 36 and 37
Revision 36 as of 2017-05-20 20:47:46
Size: 8796
Editor: GuillemJover
Comment: Add dpkg-repack merge back plan
Revision 37 as of 2017-05-20 20:50:26
Size: 8978
Editor: GuillemJover
Comment: Use DebianPkg references
Deletions are marked like this. Additions are marked like this.
Line 68: Line 68:
 * Merge back features from debuild:  * Merge back features from debuild (from DebianPkg:devscripts):
Line 77: Line 77:
 * Merge back debsums:  * Merge back DebianPkg:debsums:

  * Mostly everything in debsums is supported natively now, the following are now extensions:
Line 83: Line 85:
 * Merge back localepurge:  * Merge back DebianPkg:localepurge:
Line 87: Line 89:
 * Merge back dlocate:  * Merge back DebianPkg:dlocate:
Line 91: Line 93:
 * Merge back functionality from debsigs-verify, dpkg-sig, etc into dpkg proper (there is a pu/dpkg-sign branch now):  * Merge back functionality from DebianPkg:debsigs-verify, DebianPkg:dpkg-sig, etc into dpkg proper (there is a pu/dpkg-sign branch now):
Line 149: Line 151:
 * Move back relevant documentation from policy into dpkg.  * Move back relevant documentation from Debian policy into dpkg.

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.19.x development series

  • Propose enabling bindnow by default. Propose this again on debian-devel at the beginning of the release cycle (matching the beginning of the new dpkg series), so that any run-time problem can be possibly tracked down and fixed.

General development goals

The following are groups of tasks (many big) that should eventually get done. Consider it a task-oriented TODO list. Things that are being worked on might get moved to a specific milestone above.

  • Optimization work.

    • Faster and smaller!
  • 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).

      • It could be replaced simply with the new «dpkg-deb --ctrl-tarfile»?
    • 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 dpkg-repack:

    • Add a new --repack or --archive or similar command to dpkg that will repack the installed package into a binary package. This requires the following from dpkg:
      • Storing the original conffiles.
      • Preserving the file metadata
      • Built-in tar generator.
  • Merge back features from devscripts (reprepro):

    • Many scripts are required as part of very common development actions, and requiring the user to install anything else beyond dpkg-dev makes our toolchain more difficult to understand and use. The following are various tools, for which it would make sense to merge their functionality into dpkg proper one way or another:
    • debpkg → new dpkg option to cleanse environment.
    • dscverify and debsign → new dpkg-sign.
    • dscextract → new dpkg-source option.
    • dcmd → ??
    • dpkg-depcheck and dpkg-genbuilddeps → discuss possible takeover?
    • debchange and dch → new dpkg-modchangelog?
    • mergechanges, changestool (from reprepro) → new dpkg-modchanges.

    • wrap-and-sort, parts of cme → some new command to propose updates to the control files?

  • Merge back features from debuild (from devscripts):

    • Generates a build log (ideally while preserving colored output).
    • Runs lintian by default (dpkg-buildpackage can now be configured to do so, but it needs user action).
    • Environment cleansing.
    • Checks the source tree directory name for sanity.
    • Can use debsign/debrsign.
  • Merge back debsums:

    • Mostly everything in debsums is supported natively now, the following are now extensions:
    • Generate checksums at build time? (there is a pu/dpkg-gendigests branch now)
    • 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, can localepurge 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 debsigs-verify, dpkg-sig, etc into dpkg proper (there is a pu/dpkg-sign branch now):

    • Draft a new spec for the signature support inside .deb, discussion started on the mailing list.
    • Write a dpkg-sign (or similarly named program) in C (Depends: #refactor-deb).

    • The archive should allow signed packages. Tracked in 340306

  • Merge back functionality from other 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/? Or add generic fetch support to libdpkg-perl?
  • 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. Most of the groundwork is now there, it needs final polishing and testing to be able to enable the command.

    • A way for front-ends to store additional information for each package.
    • Unified unseen tracking:
      • dselect unseen tracking.
      • apt/aptitude unseen tracking.
    • Unified holds:
      • 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 Debian policy into dpkg.
    • Russ has mentioned this at some points, should discuss with the policy team. Part of this has been getting done, with all the new man pages, more to come though.