FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 03-01-2011, 12:36 PM
Raphael Hertzog
 
Default dpkg: multiarch symlink not present in fresh installs

Hi Colin,

following up on debian-dpkg@ since others might want to weigh in.

On Tue, 01 Mar 2011, Colin Watson wrote:
> Hi,
>
> I noticed this
> (https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/727106) while doing
> a debootstrap test of natty. I think we need to be consistent about the
> compatibility symlink being present, since it's a pain to migrate this
> from a directory to a symlink, and since I expect there to be software
> kicking around for a while that relies on it.

I deliberately added it only on upgrade. I understand you want to keep it
that way for natty but very few software should look up files directly in
/var/lib/dpkg/info/ and those that do should be converted to use
dpkg-query --control-path.

$ dpkg-query --control-path dpkg-dev md5sums
/var/lib/dpkg/info/i386/dpkg-dev.md5sums

I think it's perfectly legitimate to have the few offenders fixed in time
for wheezy.

BTW, what's difficult to move from a directory to a symlink?

$ cd /var/lib/dpkg/info
$ mv <arch>/* ./
$ rmdir <arch>
$ ln -sf . <arch>

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110301133624.GB22746@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110301133624.GB22746@rivendell.home.ouaza.com
 
Old 03-01-2011, 01:41 PM
Colin Watson
 
Default dpkg: multiarch symlink not present in fresh installs

On Tue, Mar 01, 2011 at 02:36:24PM +0100, Raphael Hertzog wrote:
> On Tue, 01 Mar 2011, Colin Watson wrote:
> > I noticed this
> > (https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/727106) while doing
> > a debootstrap test of natty. I think we need to be consistent about the
> > compatibility symlink being present, since it's a pain to migrate this
> > from a directory to a symlink, and since I expect there to be software
> > kicking around for a while that relies on it.
>
> I deliberately added it only on upgrade. I understand you want to keep it
> that way for natty but very few software should look up files directly in
> /var/lib/dpkg/info/ and those that do should be converted to use
> dpkg-query --control-path.
>
> $ dpkg-query --control-path dpkg-dev md5sums
> /var/lib/dpkg/info/i386/dpkg-dev.md5sums
>
> I think it's perfectly legitimate to have the few offenders fixed in time
> for wheezy.

Hmm. I'm honestly concerned about the inconsistency here; it will
introduce bugs that depend on how the user got there (install squeeze
and upgrade, vs. install wheezy directly), which in my experience we try
very hard to avoid.

> BTW, what's difficult to move from a directory to a symlink?
>
> $ cd /var/lib/dpkg/info
> $ mv <arch>/* ./
> $ rmdir <arch>
> $ ln -sf . <arch>

A power failure during that process will leave a corrupted dpkg
database.

--
Colin Watson [cjwatson@ubuntu.com]


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110301144146.GN22522@riva.ucam.org">http://lists.debian.org/20110301144146.GN22522@riva.ucam.org
 
Old 03-01-2011, 04:49 PM
Guillem Jover
 
Default dpkg: multiarch symlink not present in fresh installs

Hi!

On Tue, 2011-03-01 at 14:41:47 +0000, Colin Watson wrote:
> On Tue, Mar 01, 2011 at 02:36:24PM +0100, Raphael Hertzog wrote:
> > On Tue, 01 Mar 2011, Colin Watson wrote:
> > > I noticed this
> > > (https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/727106) while doing
> > > a debootstrap test of natty. I think we need to be consistent about the
> > > compatibility symlink being present, since it's a pain to migrate this
> > > from a directory to a symlink, and since I expect there to be software
> > > kicking around for a while that relies on it.
> >
> > I deliberately added it only on upgrade. I understand you want to keep it
> > that way for natty but very few software should look up files directly in
> > /var/lib/dpkg/info/ and those that do should be converted to use
> > dpkg-query --control-path.
> >
> > $ dpkg-query --control-path dpkg-dev md5sums
> > /var/lib/dpkg/info/i386/dpkg-dev.md5sums
> >
> > I think it's perfectly legitimate to have the few offenders fixed in time
> > for wheezy.
>
> Hmm. I'm honestly concerned about the inconsistency here; it will
> introduce bugs that depend on how the user got there (install squeeze
> and upgrade, vs. install wheezy directly), which in my experience we try
> very hard to avoid.
>
> > BTW, what's difficult to move from a directory to a symlink?
> >
> > $ cd /var/lib/dpkg/info
> > $ mv <arch>/* ./
> > $ rmdir <arch>
> > $ ln -sf . <arch>
>
> A power failure during that process will leave a corrupted dpkg
> database.

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.

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. Currently installed foreign
packages will also break dpkg. Fixing this implies unneeded db layout
migration for most of the packages.

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.

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.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110301174937.GA29599@gaara.hadrons.org">http://lists.debian.org/20110301174937.GA29599@gaara.hadrons.org
 
Old 03-02-2011, 07:19 AM
Raphael Hertzog
 
Default 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)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110302081920.GC4415@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110302081920.GC4415@rivendell.home.ouaza.com
 
Old 03-02-2011, 03:38 PM
Steve Langasek
 
Default dpkg: multiarch symlink not present in fresh installs

On Wed, Mar 02, 2011 at 09:19:20AM +0100, Raphael Hertzog wrote:
> 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.

Architecture: all packages are treated the same as packages for the native
arch, right? Including having all their metadata stored in the directory
for the native architecture... which means in a cross-grade where the native
architecture changes, dpkg will suddenly lose sight of all the native
packages, now treating them as packages for the new "foreign" arch when they
should be packages for the new "native" arch.

So I think Guillem is right here. Sorry for not noticing this myself
earlier.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 03-03-2011, 06:20 AM
Raphael Hertzog
 
Default dpkg: multiarch symlink not present in fresh installs

On Wed, 02 Mar 2011, Steve Langasek wrote:
> Architecture: all packages are treated the same as packages for the native
> arch, right? Including having all their metadata stored in the directory

True, I forgot about this. Thanks for the reminder.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110303072048.GE6036@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110303072048.GE6036@rivendell.home.ouaza.com
 

Thread Tools




All times are GMT. The time now is 03:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org