Hi,
There was a meeting about APT and dpkg yesterday.
Attendees: DonKult, jak, aj, mvo, XTaran, matm, mones, guillem, nthykier
* APT announced some new features. These are already on d-d-a, so I
will skip over them.
* Guillem suggested that APT moved its packages lists to a "neutral"
place, so dpkg could leverage these files (and possibly get rid of
its "Available" file).
- There was some debate how this should be done. Notable remarks:
+ The files would not be merged as they are needed for further
updates
+ There was a concern about the requirements for updating the
files there. So far only APT is doing to implement all the
necessary parts for doing it "right".
+ There was a concern about the file names being implementation
details and perhaps a frontend tool should be used instead.
* There was a suggestion to separate the "acquire" system from APT to
have it as a stand-alone feature.
- It was not apparent that the "acquire" system could trivially be
separated from APT.
* The issue about how to handle "install ordering" in APT vs. dpkg and
how to avoid --force-* options.
- Currently, APT uses a lot of --force options. Both APT and dpkg
maintainers agreed that this should be fixed.
- The dpkg maintainers suggested that APT used selections to avoid
the --force options.
- Selections can cause packages to be removed/deconfigured "under
APT's feet". APT would need to use the "--status-fd" to keep
track of such changes.
- It was agreed that APT should leave more of the low-level ordering
to dpkg. Among other things to better handle triggers.
- APT was still welcome to split things into smaller
"self-contained" units to minimise downtime etc.
(see below)
- On the other hand, dpkg would need to fully support the ordering
requirements needed.
- I did not quite catch this part. At Guillem's request I noted
the "two big states" as a keyword.
* The APT maintainers would like a way/method to have "temporal" or
"transaction lived" selections.
- It might be needed for multiple dpkg invocations (possibly by
reusing the same selection set with each call).
* The APT maintainers would look into optimising for minimal downtime
(which would involve admins to decide which services to prioritise)
- I heard "Policy" mentioned, but I wasn't sure it was a system
admin policy, the Debian policy or a third one.
* It was agreed to moved the extended status fully to dpkg, which
already provides an extensible format.
* Guillem mentioned that dpkg (and maybe APT) should probably start
supporting re-exec'ing themselves during the run.
- It would hopefully allow some features to be used during regular
upgrades (rather than waiting for another release)
- In particular, with dpkg doing most of the ordering now (see
above), it would no longer be (guaranteed to) upgraded early.
Please let me know if I missed anything, or I misremembered something.
Sadly my notes were a bit sparser than I would have liked (and my memory
might have suffered from the "Wine & Cheese party syndrome" after the
meeting). :)
Thanks,
~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature