Debian Bug report logs - #2828
have to install xosview twice to work

Toggle useless messages

Message #65 received at 2828-maintonly@bugs.debian.org (full text, mbox, reply):

From: remco@blaakmeer.student.utwente.nl (Remco Blaakmeer)

To: 2828-maintonly@bugs.debian.org

Subject: Old bugs need to be looked at

Date: Sun, 1 Feb 1998 12:00:03 +0100 (CET)

This is an automated message sent to all bugs older than one year.

This bug is very old. Please take a look at it and see if you can fix it.
If it has already been fixed, please close it.

If you have problems fixing it or if you don't have the time to fix it,
please ask the people on debian-devel@lists.debian.org for help, so that
at least the oldest bugs can be solved before Debian 2.0 is released.

Remco Blaakmeer

Message #70 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

To: 2828@bugs.debian.org

Subject: Bug#2828: Horrible aliasing problem (was xosview)

Date: Fri, 5 Mar 1999 21:37:25 +0100

Hello,

Report: 2828
Status: Open, normal.
Analyse: dpkg does not reckognize same file with different names.
Explanation:
 For example, when moving files from /usr/bin/X11/ to /usr/X11R6/bin (to fix
 a bad package), dpkg will happily remove the just installed file again.
 The sitation exists inside a single package (during an upgrade), and
 between different packages.
Strategy:
 This needs to be discussed and implemented. I think this is pretty
 important and should be aimed at probably for a new major revision
 of dpkg (2.0 perhaps?).
 Several suggestions were made, but no convincing.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

Message #75 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Adam Heath <doogie@debian.org>

To: 2828@bugs.debian.org

Cc: Raul Miller <rdm@tad.micro.umn.edu>, Ian Jackson <ian@chiark.chu.cam.ac.uk>, joost witteveen <joost@rulcmc.leidenuniv.nl>, Dirk.Eddelbuettel@qed.econ.queensu.ca, Stephen Early <sde1000@chiark.chu.cam.ac.uk>

Subject: dpkg bug: have to install xosview twice to work

Date: Fri, 5 Mar 1999 18:17:00 -0600 (CST)

Someone mentioned this on irc, and I had a possible solution.

Dpkg gets the file list for the new, updated pkg, and compares that to the
installed list.  Any files not in the new pkg, get renamed to <file>.dpkg.#,
and it is these backups that get removed after the pkg is fully unpacked.

The rename is done in the current directory of the file, so you shouldn't have
symlink probs, unless the admin used a symlink on just one file, but in that
case, you are screwed anyways.

Adam

Message #80 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@azure.humbug.org.au>

To: 2828@bugs.debian.org

Subject: Re: dpkg bug: have to install xosview twice to work

Date: Tue, 5 Oct 1999 14:01:59 +1000

[Message part 1 (text/plain, inline)]

Some thoughts, fwiw:

The seuqence of events seems to be:

Setup:
	* /dir and /link refer to the same directory.
	* installed file known as /dir/filename
	* to-be-installed file known as /link/filename

Check-for-overwriting:
	Are there any dpkg-controlled files that /link/filename will
	overwrite? dpkg checks this by just looking for /link/filename
	in /var/lib/dpkg/info/*.list

	If so:
		Is it in this package itself?
		Does this package replace it?
		Is --force-overwrites enabled?
			If so, overwrite it, but make a note not to delete
			the now-overwritten file later.

		Otherwise, there's an error.

Write the file
Delete any files left in the package


Okay. Based on that, there are a few overwriting cases:

	* it's in the package, or a replaced package by the same name

		-- easily checked

	* it's in the package, or a replaced pacakge by a different name

		-- can be checked by stating each directory of files in the
		   package, in the previously installed version of the package
		   and in every installed package it replaces.

		   the most directories in any package on my system is
		   281, (average is about 15), the most packages any
		   package replaces is 14 (most replace no more than 4).

		   This at least lets you get the `legal' situations correct.

	* it's in some other package by the same name

		-- easily checked

	* it's in some other package by a different name

		-- can be checked by stating each directory of files in any
		   package and canoncolising them. There are about 2849
		   such directories on my system, and it takes about 30s to
		   stat them all. (Which is probably twice? how long dpkg
		   takes to start up)

	* it's installed locally by the sysadmin 

		-- should get overwritten anyway

Another possibility would be adding a --no-force-local-overwrite (or
similar) option that warns/fails if dpkg tries to overwrite a file that
doesn't appear to be in the dpkg database (which would be the case if
the admin installed it, or if it appears under another name in some
unrelated package). This could be used for testing in much the same way
as --no-force-overwrite is at the moment.

Somewhat relatedly, the sysadmin can already break things by, eg:

	# dpkg -i a.deb b.deb
	# rm -rf /usr/doc/a
	# ln -s b /usr/doc/a
	# dpkg --purge a
	# less /usr/doc/b/changelog.gz
	/usr/doc/b/changelog.gz: No such file or directory

This could be avoided by doing the stating all the time, and noticing
on the --purge that /usr/doc/a/changelog.gz and /usr/doc/b/changelog.gz
are actually the same file and not actually rm'ing it until no packages
are using it.

Anyway, assuming we're not going to go worry too much about correct
behaviour in the above example, just stating the directories in packages
that are actually getting replaced would probably be both efficient,
and correct in most cases.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

[Message part 2 (application/pgp-signature, inline)]

Message #85 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: wakkerma@debian.org

Cc: 2828@bugs.debian.org, debian-devel@lists.debian.org

Subject: [PATCH] check dev/inode before removing old files on upgrade

Date: Sun, 10 Oct 1999 22:12:24 -0400

[Message part 1 (text/plain, inline)]

This fixes one of the major bugs in dpkg, IMO. Referenced in #2828 and
others over time. Basically this is the symlink problem in dpkg which
forced the kludge we are now using on the /usr/doc upgrade.

Normally when dpkg unpacks files, it recognizes new files based on file
names alone in the packages .list. This breaks when a file in package "a_1"
is actually the same as then one in package "a_2" (same package, different
versions), but are referenced differently because of directory symlinks
on the system. Eg. if /usr/doc were a symlink to /usr/share/doc and package
"a_1" used /usr/doc, but "a_2" used /usr/share/doc, dpkg would install the
new doc files (/usr/share/doc/changelog.gz) but then remove the common files
when getting rid of the files from "a_1" that it thought were not in the
newer version (/usr/doc/changelog.gz, which follow to the same file).

The work around is for dpkg to check each file it removes on upgrading the
package against the files in the new version, by stat'ing them and comparing
dev/inode. If there is a match, dpkg leaves it alone since they are the
same file. This is further sped up by only having to stat the new files once
on the first loop, so for more than one old file, there is not much performance
loss (barely measurable using `time').

Enjoy,
  Ben

[stat.patch (text/plain, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #90 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Wichert Akkerman <wichert@liacs.nl>

To: Ben Collins <bcollins@debian.org>

Cc: 2828@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: [PATCH] check dev/inode before removing old files on upgrade

Date: Mon, 11 Oct 1999 04:24:00 +0200

[Message part 1 (text/plain, inline)]

Previously sparc porters wrote:
> The work around is for dpkg to check each file it removes on upgrading the
> package against the files in the new version, by stat'ing them and comparing
> dev/inode.

Should you be using lstat here?

Wichert.

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@liacs.nl                    http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

[Message part 2 (application/pgp-signature, inline)]

Message #95 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: 2828@bugs.debian.org, debian-devel@lists.debian.org

Cc: wakkerma@debian.org

Subject: Re: [PATCH] check dev/inode before removing old files on upgrade

Date: Sun, 10 Oct 1999 22:45:23 -0400

On Mon, Oct 11, 1999 at 04:24:00AM +0200, Wichert Akkerman wrote:
> Previously sparc porters wrote:
> > The work around is for dpkg to check each file it removes on upgrading the
> > package against the files in the new version, by stat'ing them and comparing
> > dev/inode.
> 
> Should you be using lstat here?

Yes, because when dpkg replaces existing files, it doesn't follow symlinks. It
always replaces the destination with the new file/symlink. A file being removed
is also not followed, the actual symlink is removed. Just think of symlinks in
the /usr/doc directory being the same as the symlink in the (linked)
/usr/share/doc directory.

Ben

Message #100 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@azure.humbug.org.au>

To: Ben Collins <bcollins@debian.org>

Cc: wakkerma@debian.org, 2828@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: [PATCH] check dev/inode before removing old files on upgrade

Date: Mon, 11 Oct 1999 13:54:39 +1000

[Message part 1 (text/plain, inline)]

On Sun, Oct 10, 1999 at 10:12:24PM -0400, Ben Collins wrote:
> The work around is for dpkg to check each file it removes on upgrading the
> package against the files in the new version, by stat'ing them and comparing
> dev/inode. If there is a match, dpkg leaves it alone since they are the
> same file. This is further sped up by only having to stat the new files once
> on the first loop, so for more than one old file, there is not much performance
> loss (barely measurable using `time').

Consider:

	a_1.deb contains /usr/bin/X11/xa
	a-mod_1.deb conflicts,replaces: a, and contains /usr/X11R6/bin/xa

Installing a-mod_1 over a_1 results in /usr/X11R6/bin/xa disappearing.

This doesn't look at all easy to fix, and it's probably not too important
in any case, but it's probably worth noting in the `sanity' comment.

(This'd cause problems if, eg, someone moved /usr/doc/foo/foo.ps.gz
from foo into foo-doc in the same release cycle they did the /usr/doc ->
/usr/share/doc transition; assuming we had a /usr/doc -> /usr/share/doc
link)

You might also like to include a debug(dbg_eachfile, "...") comment of
some sort, too.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

[Message part 2 (application/pgp-signature, inline)]

Message #105 received at 2828@bugs.debian.org (full text, mbox, reply):

From: ron@microtronics.com.au (Ron)

To: Ben Collins <bcollins@debian.org>, 2828@bugs.debian.org

Cc: wichert@liacs.nl

Subject: Re: Bug#2828: [PATCH] check dev/inode before removing old files on upgrade

Date: Mon, 11 Oct 1999 13:53:35 +0930 (CST)

> This fixes one of the major bugs in dpkg, IMO. Referenced in #2828 and
> others over time. Basically this is the symlink problem in dpkg which
> forced the kludge we are now using on the /usr/doc upgrade.

I'm feeling very wary about even bringing this up given the history of
this debate..  but does this really mean that we could now more optimally
symlink /usr/doc to /usr/share/doc and abandon the present proposal to
add maintainer scripts to every package?

If so, I for one would like to see that happen.  I have at least one
machine that I suspect will run into drive space problems as a result
of the current proposal.  (yes, its an old machine - no I don't really
want to add new drives to it, it has 4 ide drives in it now.  Yes, I
deliberately packed it very full - no I don't really want to have to
delete some of the packages installed on it just so I can keep the rest
up to date.. ;-)

best,
Ron.

what would be the worst case of changing our /usr/doc policy to use
this single symlink?  A versioned dependency on dpkg with your patch
for packages that could be subject to the doc location transition??

Message #110 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: wakkerma@debian.org, 2828@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#2828: [PATCH] check dev/inode before removing old files on upgrade

Date: Mon, 11 Oct 1999 08:17:14 -0400

On Mon, Oct 11, 1999 at 01:54:39PM +1000, Anthony Towns wrote:
> On Sun, Oct 10, 1999 at 10:12:24PM -0400, Ben Collins wrote:
> > The work around is for dpkg to check each file it removes on upgrading the
> > package against the files in the new version, by stat'ing them and comparing
> > dev/inode. If there is a match, dpkg leaves it alone since they are the
> > same file. This is further sped up by only having to stat the new files once
> > on the first loop, so for more than one old file, there is not much performance
> > loss (barely measurable using `time').
> 
> Consider:
> 
> 	a_1.deb contains /usr/bin/X11/xa
> 	a-mod_1.deb conflicts,replaces: a, and contains /usr/X11R6/bin/xa
> 
> Installing a-mod_1 over a_1 results in /usr/X11R6/bin/xa disappearing.
> 
> This doesn't look at all easy to fix, and it's probably not too important
> in any case, but it's probably worth noting in the `sanity' comment.

Yeah, the "insanity" would be stating every file on the system for each package
upgrade :) I'm not sure, there may be a way to keep a *namenode list of the
replaced files and check those too.

> You might also like to include a debug(dbg_eachfile, "...") comment of
> some sort, too.

Yeah, it's an easy addition.

Ben

Message #115 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: 2828@bugs.debian.org

Cc: wakkerma@debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Mon, 11 Oct 1999 09:04:11 -0400

[Message part 1 (text/plain, inline)]

Ok, new patch. This just adds some to the comments about why we only check
this package. I looked into the replaces issue, and it doesn't seem very
feasible right now. I also added some debug() output.

Ben

[stat.patch (text/plain, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #120 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <moth@debian.org>

To: Ron <ron@microtronics.com.au>, 2828@bugs.debian.org

Cc: Ben Collins <bcollins@debian.org>, wichert@liacs.nl

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Mon, 11 Oct 1999 15:09:26 -0400

On Mon, Oct 11, 1999 at 01:53:35PM +0930, Ron wrote:
> I'm feeling very wary about even bringing this up given the history
> of this debate.. but does this really mean that we could now more
> optimally symlink /usr/doc to /usr/share/doc and abandon the present
> proposal to add maintainer scripts to every package?

I already asked Ben about this.  Paraphrased, his response was roughly:
that ought to work but he doesn't have time to test to see if there
are any other implications.

-- 
Raul

Message #125 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Wichert Akkerman <wichert@liacs.nl>

To: Raul Miller <moth@debian.org>

Cc: Ron <ron@microtronics.com.au>, 2828@bugs.debian.org, Ben Collins <bcollins@debian.org>

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Wed, 13 Oct 1999 17:59:04 +0200

[Message part 1 (text/plain, inline)]

Previously Raul Miller wrote:
> I already asked Ben about this.  Paraphrased, his response was roughly:
> that ought to work but he doesn't have time to test to see if there
> are any other implications.

We also have to realize that people may be using an older dpkg, so relying
on this fix is not an option.

Wichert.

-- 
  _________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@liacs.nl                    http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

[Message part 2 (application/pgp-signature, inline)]

Message #130 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Wichert Akkerman <wichert@liacs.nl>

Cc: Raul Miller <moth@debian.org>, Ron <ron@microtronics.com.au>, 2828@bugs.debian.org

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Wed, 13 Oct 1999 12:08:56 -0400

On Wed, Oct 13, 1999 at 05:59:04PM +0200, Wichert Akkerman wrote:
> Previously Raul Miller wrote:
> > I already asked Ben about this.  Paraphrased, his response was roughly:
> > that ought to work but he doesn't have time to test to see if there
> > are any other implications.
> 
> We also have to realize that people may be using an older dpkg, so relying
> on this fix is not an option.

Then making the /usr/doc become a symlink to /usr/share/doc (and all the
moving invloved with it) should be in a base package that depends on
_that_ version of dpkg (most likely basefiles itself).

Then the worst scenario is using newer packages without the newer
basefiles/dpkg, which would simply have some docs in /usr/doc and some in
/usr/share/doc. All of this being fixed by the upgrade to the
dpkg/basefiles that support this change.

Ben

Message #135 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <moth@debian.org>

To: Wichert Akkerman <wichert@liacs.nl>

Cc: Ron <ron@microtronics.com.au>, 2828@bugs.debian.org

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Wed, 13 Oct 1999 12:22:01 -0400

On Wed, Oct 13, 1999 at 05:59:04PM +0200, Wichert Akkerman wrote:
> We also have to realize that people may be using an older dpkg, so relying
> on this fix is not an option.

Hmm.. I guess dpkg isn't smart enough to deal properly with the case
where there's a Pre-Depends: on dpkg?

How about this, as a kludge: at the tail end of dpkg's postinst, check
for a currently running version of dpkg with that multiple-ref handling
bug -- if it's running, clean up the db a little then kill that dpkg.

-- 
Raul

Message #140 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Wichert Akkerman <wichert@liacs.nl>

To: Ben Collins <bcollins@debian.org>

Cc: Raul Miller <moth@debian.org>, Ron <ron@microtronics.com.au>, 2828@bugs.debian.org

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Wed, 13 Oct 1999 18:22:27 +0200

[Message part 1 (text/plain, inline)]

Previously Ben Collins wrote:
> Then making the /usr/doc become a symlink to /usr/share/doc (and all the
> moving invloved with it) should be in a base package that depends on
> _that_ version of dpkg (most likely basefiles itself).

However packages are already using this solution and it is (almost) policy.
I would rather continue using that solution and not adding a dependency
to a specific dpkg or base-files version to every package..

Wichert.

-- 
  _________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@liacs.nl                    http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

[Message part 2 (application/pgp-signature, inline)]

Message #145 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Wichert Akkerman <wichert@liacs.nl>

Cc: Raul Miller <moth@debian.org>, Ron <ron@microtronics.com.au>, 2828@bugs.debian.org

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Wed, 13 Oct 1999 12:30:37 -0400

On Wed, Oct 13, 1999 at 06:22:27PM +0200, Wichert Akkerman wrote:
> Previously Ben Collins wrote:
> > Then making the /usr/doc become a symlink to /usr/share/doc (and all the
> > moving invloved with it) should be in a base package that depends on
> > _that_ version of dpkg (most likely basefiles itself).
> 
> However packages are already using this solution and it is (almost) policy.
> I would rather continue using that solution and not adding a dependency
> to a specific dpkg or base-files version to every package..
> 
> Wichert.

Note, that the current method works well with this solution. The postinst
and prerm don't act if what they find exists or is not a symlink,
respectively.

Ben

Message #150 received at 2828@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <moth@debian.org>

To: 2828@bugs.debian.org

Cc: Wichert Akkerman <wichert@liacs.nl>, Ron <ron@microtronics.com.au>

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Wed, 13 Oct 1999 13:29:56 -0400

On Wed, Oct 13, 1999 at 12:22:01PM -0400, Raul Miller wrote:
> Hmm.. I guess dpkg isn't smart enough to deal properly with the case
> where there's a Pre-Depends: on dpkg?

Also, we're maybe getting too close to release to introduce anything
strategic like this that hasn't gone through a lot of testing.

-- 
Raul

Message #155 received at 2828@bugs.debian.org (full text, mbox, reply):

From: ron@microtronics.com.au (Ron)

To: Wichert Akkerman <wichert@liacs.nl>

Cc: Ben@microtronics.com.au, Collins <bcollins@debian.org>, Raul@microtronics.com.au, Miller <moth@debian.org>, 2828@bugs.debian.org

Subject: Re: Bug#2828: PATCH] check dev/inode before removing old files on upgrade

Date: Thu, 14 Oct 1999 03:37:30 +0930 (CST)

Wichert writes:
> Previously Ben Collins wrote:
> > Then making the /usr/doc become a symlink to /usr/share/doc (and all the
> > moving invloved with it) should be in a base package that depends on
> > _that_ version of dpkg (most likely basefiles itself).
> 
> However packages are already using this solution and it is (almost) policy.
> I would rather continue using that solution and not adding a dependency
> to a specific dpkg or base-files version to every package..

..actually, if I read correctly what Ben is saying,

> > Then the worst scenario is using newer packages without the newer
> > basefiles/dpkg, which would simply have some docs in /usr/doc and some in
> > /usr/share/doc. All of this being fixed by the upgrade to the
> > dpkg/basefiles that support this change.

then we need to do very little.  The _only_ dependency that would be
required is for the base package that creates the /usr/doc->/usr/share/doc
symlink to depend on the patched version of dpkg.

All other packages could remain happily oblivious to the change.
Even ones that are already using the new symlink policy.

Old packages still put files in /usr/doc, new ones in /usr/share/doc
and anyone who is concerned about having docs in two locations only
needs to install the new base package to put things as they would like.

And packages not yet updated only need to move their doc location
at the next upload and don't need to bother about adding the
proposed maintainer scripts.

To paraphrase Asimov, we'd have a class A outcome from a class F
stimulus. ;-)

..and full FHS compliance (for /usr/share/doc anyway) for potato
handled by essentially a single package upgrade.

   Ron.

Send a report that this bug log contains spam.