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