Hi, On Tue, 01 Mar 2011, Guillem Jover wrote: > As I mentioned on the IRC channel, and to Steve in particular when he > mentioned the Ubuntu dpkg upload, the current db layout is defintely > not the final one. It has several problems, mainly of fragility as you > point out.
What's fragile? It's inconsistent between upgrade and fresh install but it only becomes fragile when you want to fix that inconsistency which I'm not convinced is required. > The dpkg db (status, info control files, etc) should *never* get into > a state from where it cannot be recovered, at least from "normal" > operations. With the current multiarch db layout crossgrading dpkg > (something that is currently supported, although with a --force > option) will completely break dpkg. I might miss the obvious but how? There's one directory per arch and you can certainly switch the native architecture from one to the other and the references are still consistent. The current implementation doesn't allow a cross-grade and might not do the right thing if you force it but that is not an inherent problem with the db layout but rather with the implementation. I agree though that your suggested layout might make it easier to support those cross-grades. But if you think that's important it would have been nice to have reacted to <[email protected]> when I asked whether it's important to support it. :) > The new db layout I've been working on, uses «<admindir>/pkg.file» for > all packages except multiarch_same which use «<admindir>/pkg:arch.file» > (falling back to «<admindir>/pkg.file» if the former is not present), > which are the only ones needing to be distinguished among them. It does > not really matter if we have a foreign package installed, as we can only > have one at any point in time. The multiarch_same packages will get > their db layout transparently upgraded when any of it's instaces gets > installed. I've also added checks checks and two-staged safe db layout > downgrade support on dpkg downgrade. I hope to have something pushable > probably today. I wish you had told this from the beginning when I drafted the implementation plan. > The dpkg crossgrade scenario also has implications for the pkg names > when interfacing with dpkg (either input or output). For example, if > we assume pkg for native and pkg:arch for foreign packages, then on > crossgrade the world view of apt and dpkg will not match at some point > in the upgrade. So it's never safe to assume libsame == libsame:native. > I'll come back to this on the previous thread about multiarch package > names, later today. I don't think it's relevant. Neither dpkg nor apt rely internally on libsame == libsame:native. However they present it to the user that way and they expect the user to follow that convention. The dpkg crossgrade is a one-time operation and indeed it changes the world view of the user. But the user knows he switched dpkg to another architecture. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
