Re: dpkg transactions
Hello!
2015-01-13 21:39, Guillem Jover:
> [ Adding apt and cupt back into the CCs, as this is frontend related,
> as I'm not sure if you all are subscribed to debian-dpkg. ]
I am subscribed, but thanks, maybe even there is someone interested
reading Cupt mailing lists :)
The "dpkg line" seems to be same what we were discussing in a bug
tracker. But as it's now with wider auditory, I take a chance to include
my up-to-date view FWIW.
part 1: my plans for near future
--------------------------------
After our last discussion with Guillem in Cupt bug tracker about
--force, I decided that, following the official dpkg's line, at some
point Cupt will experiment with starting using dpkg selections and see
if it's possible to avoid passing --force-* options without losing
something. I don't plan though to setting them globally for the whole
planned actions, but instead step-by-step, at each step just enough so
dpkg can unwind the next complex action with --force; let's see how it
goes.
part 2: what interfaces dpkg would have in my ideal world
---------------------------------------------------------
In my ideal world, dpkg would provide just the necessary low-level
interfaces to manipulate package states (preferably, from a C or C++
shared library), namely 'unpack', 'configure', 'deconfigure' and
'deunpack', and probably 'run-triggers' or similar. In such world,
package ordering or any guesses of such doesn't belong to lower-level
package manager but it's the higher-level front-end job. I could imagine
several scenarios why front-ends may want to select different orderings
from a set of valid ones. I see some points in 'do giant dpkg --xyz *.deb'
call, but I wouldn't go that way.
part 3: back to reality
---------------
Cupt is a minor player and therefore will try to utilise whatever the
latest and greatest dpkg offers :)
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org
C++ GNU/Linux userspace developer, Debian Developer
Reply to: