Differences between revisions 18 and 19
Revision 18 as of 2011-01-25 19:10:16
Size: 8356
Editor: GuillemJover
Comment: Update
Revision 19 as of 2011-04-02 04:07:28
Size: 6582
Editor: GuillemJover
Comment: Update for 1.16.x
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
== The 1.15.x “merge back” development series == == The 1.16.x “merge back” development series ==
Line 67: Line 67:
 * (./) Support xz compression. <<Anchor(xz)>>

  * (./) Transition the lzma read/write support to xz.
  * Deprecate lzma write support.
 * Deprecate lzma write support.
Line 74: Line 71:
  * (./) Find an acceptable way to provide default values to build flags (CFLAGS and al.),
  given the last discussion it's probably by implementing a new dpkg-buildflags tool.
  Related to: DebianBug:489771
Line 83: Line 77:
 * (./) Make dpkg.deb contain only sh and C programs (to help embedded distros,
 to make it possible to remove perl-base from essential): <<Anchor(c-rewrite)>>

  * (./) Move install-info to its own package built from src:info.
  * (./) Rewrite mksplit in C or merge it into dpkg-split (Depends: [[#refactor-deb]], almost finished in pu/c-rewrite).
  * (./) Rewrite dpkg-statoverride in C.
  * (./) Rewrite dpkg-divert in C (almost finished on pu/c-rewrite).
  * (./) Rewrite u-a in C: (beginnings in pu/c-rewrite). /!\ RaphaelHertzog is working on it.
Line 95: Line 80:
  * (./) Try not to inflict setjmp on users by default (provide callbacks, code in pu/no-setjmp-error-handlers).
Line 100: Line 84:
  * (./) Switch to link with shared libraries instead of statically.
  * (./) New libdpkg-dev package.
Line 103: Line 85:

 * (./) New perl modules package: <<Anchor(libdpkg-perl)>>

  * (./) Move Dpkg.pm to libdpkg-perl (c-rewrite not a blocker, the file can stay in dpkg, as libdpkg-perl will need to depend on dpkg anyway).
  * (./) Review of all APIs, cleanup, etc ([[Teams/Dpkg/PerlAPICleanup]]).
  * (./) Document perl modules.
  * (./) New libdpkg-perl package.
Line 121: Line 96:
    * (./) Implement invoke hooks.
    * (./) Implement db control-path printing.
Line 142: Line 115:
  * (./) Mostly finishing and merging the pu/filters branch. <<Anchor(filters)>>
Line 163: Line 135:
   * Depending on the discussions might need either [[#refactor-deb]] or [[#filters]], or other stuff.    * Depending on the discussions might need either [[#refactor-deb]] or filters (implemented), or other stuff.
Line 167: Line 139:
  * (./) Rename dpkg-ftp as dselect-ftp.
  * (./) Rename dpkg-multicd as dselect-multicd.
  * (./) Consider changes to local dpkg-scanpackages in dpkg-multicd.

Dpkg Roadmap

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

The 1.16.x “merge back” development series

  • Multiarch support.

    • Specify and print allowed architectures.
      • (./) Add support for /etc/dpkg/dpkg.cfg.d/.

      • (./) New «dpkg --print-foreign-architectures» (or similar). (DONE, list)

      • (./) New «dpkg --foreign-architecture» (or similar, multiple calls or comma separated values). (DONE, list)

    • dpkg related sub-commands run from maintainers scripts might need to know the package architecture (dpkg-query, dpkg-trigger, etc?).
      • (./) New DPKG_MAINTSCRIPT_ARCH env var.

      • (!) Or explicit <pkgname>:<arch> on command line.

    • Issues when printing package information, or when specifiying package on the command line (admin PoV).
      • «dpkg -l», «dpkg -S», «dpkg -L» ...
      • (!)

        If (supported arches > 1 && pkg.arch == foreign)
          Print pkg:arch;
        Else
          Print pkg;
        • pkg:arch should always be used for foreign packages and the lack of architecture qualifier must imply that we're referring to the native package. Otherwise the same output can refer to different things depending on the system where it was generated. --RaphaelHertzog

      • (!) Default to assume pkg:native on input.

    • Consider if libs with different ABI per arch are going to be problematic (libc6 vs libc6.1):
      • Should not have non-versioned files!
      • Different pkgname anyway.
      • ...
    • Compare/checksum/hash files to avoid conflicts if they match and they are allowed to due to Multi-Arch:same.

      • Same contents and metadata.
      • If (pkgA.name == pkgB.name && pkgA.multiarch_same && pkgB.multiarch_same && fileA == fileB)
          No Conflict;
    • (./) Implement Multi-Arch field parsing and dumping. (DONE, pu/multiarch)

    • In-core storage of co-installable pkg data.
      • Should store in a different struct data that might differ per arch package (pkginfoperfile → per arch?):
        • Package metadata (arch, depends, priority?).
        • File info (file paths, checksums?).
    • On-disk storage of foreign (and co-installable) pkg data.
      • Currently only one instance of pkgname can be loaded per parsing.
      • Control files database path changes (need the arch somewhere).
      • (./) Need an interface to get database control file paths (at least for non internal ones).

      • (!) Can use opportunity to poolize /var/lib/dpkg/info dir (optimization).

    • (./) Apply new Multi-Arch semantics on dependency relationships. (DONE, list)

  • Optimization work.

    • Faster and smaller!
  • Deprecate lzma write support.
  • Package building infrastructure fixes:
    • Allow usage of build-arch/build-indep rules for the few packages that would really benefit from it.

      Tracked in: 229357

    • 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 and install time. 155676

    • Store metadata from .deb at install time.
    • Add a new dpkg-foo to verify, restore, etc metadata.
  • Merge back localepurge:
    • After that 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.
    • Write a dpkg-sig (or similarly named program) in C (Depends: #refactor-deb).

    • The archive should allow signed packages. Tracked in 340306

  • Merge back dpkg-cross (Depends: #mulitarch):

  • 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.
    • Discuss the supposed need of front-ends to use --force options, when they should use selections instead as transactions.
    • A way for front-ends to store additional information for each package.
    • 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.