5080
Comment:
|
7214
Add multiarch implementation notes and roadmap
|
Deletions are marked like this. | Additions are marked like this. |
Line 6: | Line 6: |
* 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; }}} * (!) 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) |
Dpkg Roadmap
The 1.15.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;
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?).
- Should store in a different struct data that might differ per arch package (pkginfoperfile → per arch?):
- 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)
- Specify and print allowed architectures.
Optimization work.
- Faster and smaller!
Support xz compression.
- Transition the lzma read/write support to xz.
- Deprecate lzma write support.
Generate new source formats by default:
- Blocked on ftp-master accepting them.
Most of the reported bugs be fixed (Projects/DebSrc3.0).
- Package building infrastructure fixes:
- 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: 489771
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).
- 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.
- Make dpkg.deb contain only sh and C programs (to help embedded distros,
to make it possible to remove perl-base from essential):
Move install-info to its own package built from src:info.
Rewrite mksplit in C or merge it into dpkg-split (Depends: #refactor-deb).
Rewrite dpkg-statoverride in C.
- Rewrite dpkg-divert in C.
- Rewrite u-a in C.
New dpkg shared library:
- Library API cleanup and general code refactoring.
- Try not to inflict setjmp on users by default (provide callbacks).
- Provide pluggable allocators to avoid leaking through nfmalloc.
- 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.
- Switch to link with shared libraries instead of statically.
- New libdpkg0, libdpkg0-dbg and libdpkg-dev packages.
New perl modules package:
- Move Dpkg.pm to libdpkg-perl (c-rewrite not a blocker, need to depend on dpkg anyway).
Review of all APIs, cleanup, etc (?Teams/Dpkg/PerlAPICleanup).
- Document perl modules.
- New libdpkg-perl package.
- 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 invoke hooks.
Implement db control-path printing.
- Implement --reconfigure??
- 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.
- Store metadata from .deb at install time.
- Add a new dpkg-foo to verify, restore, etc metadata.
- Merge back localepurge:
Mostly finishing and merging the filters branch.
- 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).
Merge back dpkg-cross (Depends: #mulitarch):
Need a spec for cross multiarch support, draft at https://wiki.ubuntu.com/MultiarchCross.
- Implement cross multiarch support (if needed).
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, or other stuff.
- Clean up dpkg namespace:
Rename dpkg-ftp as dselect-ftp.
Rename dpkg-multicd as dselect-multicd.
Consider changes to local dpkg-scanpackages in dpkg-multicd.
- 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.
- A way for front-ends to store additional information for each package.
- Other stuff, would need to ask front-end developers.
- Discuss and decide about dpkg knowledge of repository information.
- Move back relevant documentation from policy into dpkg.
- Russ has mentioned this at some points, should discuss with the policy team.