Re: dpkg: multiarch symlink not present in fresh installs
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 <20110218113118.GA7140@rivendell.home.ouaza.com> 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)
Reply to: