Forwarded message from Roman Hodek, 15:32:01 Tue,27 January 1998
--OJJBR7lUBv
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Received: from tiamat.datasync.com (srivasta@tiamat.datasync.com [205.216.83.252])
by tiamat.datasync.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id IAA24900
for <srivasta@tiamat.datasync.com>; Tue, 27 Jan 1998 08:55:39 -0600
Received: from mail.datasync.com
by tiamat.datasync.com (fetchmail-4.3.5 POP3)
for <srivasta@tiamat.datasync.com> (single-drop); Tue, 27 Jan 1998 08:55:40 CST
Received: by osh5 for srivasta
(with Cubic Circle's cucipop (v1.21 1997/08/10) Tue Jan 27 08:55:37 1998)
X-From_: rnhodek@faui21.informatik.uni-erlangen.de Tue Jan 27 08:32:07 1998
Received: from faui21.informatik.uni-erlangen.de (root@faui21.informatik.uni-erlangen.de [131.188.32.21]) by osh5.datasync.com (8.8.7/Datasync) with ESMTP id IAA31500 for <srivasta@datasync.com>; Tue, 27 Jan 1998 08:32:06 -0600
Received: from faui22c.informatik.uni-erlangen.de (faui22c.informatik.uni-erlangen.de [131.188.32.72])
by faui21.informatik.uni-erlangen.de (8.8.8/8.8.8/7.3t-FAU) with ESMTP id PAA14486;
Tue, 27 Jan 1998 15:32:07 +0100 (MET)
Received: (from rnhodek@localhost)
by faui22c.informatik.uni-erlangen.de (8.8.8/8.8.8/cl-FAU) id PAA20360;
Tue, 27 Jan 1998 15:32:01 +0100 (MET)
Message-Id: <199801271432.PAA20360@faui22c.informatik.uni-erlangen.de>
Reply-to: Roman.Hodek@informatik.uni-erlangen.de
X-List: to-me
X-Spam: Addressed
X-Filter: mailagent [version 3.0 PL58] for srivasta@tiamat.datasync.com
From: Roman Hodek <rnhodek@immd2.informatik.uni-erlangen.de>
To: srivasta@datasync.com
Subject: Re: Conflict ordering in pkg-order
Date: Tue, 27 Jan 1998 15:32:01 +0100 (MET)
Hi Manoj!
Today I've tested my last pkg-order patch in dftp with a bigger test
case. First the good news: The 'Noconflict' stuff works fine so far, I
don't have to delete/mark to-be-updated packages anymore. Also the
conflict ordering works correct most of the time.
The bad news: For some packages, I now get dependency cycles :-( This
is due to the fact that some libc5 compat packages depend on their
libc6 variant! Examples are xview[g], libpaper[g], and e2fsprogs&Co.
Here are the relevant excerpts from the Packages file:
Package: libpaper
Version: 1.0.3-6
Depends: libc5 (>= 5.4.0-0), libpaperg
Package: libpaperg
Version: 1.0.3-6
Depends: libc6
Conflicts: libpaper (<< 1.0.3-4)
I think these two can never be installed (if an old libpaper is
present) without some kind of errors... :-( You can't install
libpaperg without an appropriately new libpaper, and that not without
libpaperg... some kind of catch-22, isn't it :-)
Package: xview
Version: 3.2p1.4-2
Depends: libc5 (>= 5.4.0-0), xlib6 (>= 3.2-0), xviewg (= 3.2p1.4-2)
Package: xviewg
Version: 3.2p1.4-2
Depends: libc6, xlib6g (>= 3.3-5)
Conflicts: xview (<< 3.2p1.4-1)
Replaces: xview
This is basically the same as above, but with an additional Replaces:.
Think this is for taking over some files of old xview, not related to
libc5/libc6 issues.
Package: e2fslibsg
Version: 1.10-10
Depends: comerr2g, libc6
Conflicts: e2fsprogs (<= 1.10-7)
Package: comerr2g
Version: 1.10-10
Depends: libc6
Conflicts: e2fsprogs (<< 1.10-6), comerr2
Package: e2fsprogs
Version: 1.10-10
Depends: comerr2g, e2fslibsg, libc6
Conflicts: e2fsprogsg
Here it seems a bit more difficult, also because three packages are
involved. But e2fsprogs depends on both, comerr2g and e2fslibsg, and
those again conflict with earlier versions of e2fsprogs, which gives
the cycler later.
Are you the same opinion that in cases of libpaper and xview the
additional dependencies are bogus and should be removed? If yes, I'll
report bugs against those packages. Or do I miss something?
But in the case of e2fsprogs is more complicated. If you have an old
(<= 1.10-6) e2fsprogs installed, that should be updated first.
Otherwise, the libs should be installed first to satisfy dependencies
of e2fsprogs. What to do here??
The other question --putting aside the question whether the real error
is in the packages-- is how to work around these cases in pkg-order. A
"tsort: cycle in data" output really isn't nice... There are two
possibilities: (1) omit the implicit dependency coming from the
Conflicts, or (2) the real, bogus dependency.
pro (1):
- easier to implement: Just another check before issueing the faked
dependency
- (2) would lead to an error during installation; dpkg sees the
dependency and complains that libpaperg/xviewg isn't
installed/configured yet
pro (2):
- seems a bit more correct, since the real dependency is bogus
- Also (1) leads to an dpkg error if an too old version (the one
conflicted with) is installed
Which solution is less bad now? :-) I think (1) ... The following
patch implements it. I also added some comments and introduced a new
variable $name as abbreviation for $params->{'Package'}->{'Package'},
which is used several times, and a warning is issued if ordering due
to conflict cannot be done. Omit that warning if you don't like it...
Roman
------------------------------------------------------------------------------
--- Dependency.pm~ Tue Jan 27 15:08:37 1998
+++ Dependency.pm Tue Jan 27 15:28:54 1998
@@ -549,19 +549,30 @@
my $self = shift;
my $params = shift; # I know, this is unusual
my @providers;
-
+ my $name;
+
croak("Required parameter Package absent") unless
- $params->{'Package'}->{'Package'};
+ ($name = $params->{'Package'}->{'Package'});
croak("Required parameter New package list absent")
unless $params->{'New'};
-
+
+ # Conflicts: p (<< v) can also introduce implicit dependencies, if a
+ # version << v of p is installed. Then the update must come first to
+ # avoid a dpkg error.
if ($self->{'Type'} eq 'Conflicts') {
- if ($self->{'Rel'} &&
- ($self->{'Rel'} eq '<<' || $self->{'Rel'} eq '<=') &&
- $params->{'New'}->{$self->{'Name'}}->{'Package'}) {
- push(@{$params->{'Package'}->{' _Order'}},
- "$self->{'Name'} $params->{'Package'}->{'Package'}");
+ if (# has a relation, which is << or <=
+ $self->{'Rel'} && ($self->{'Rel'} eq '<<' || $self->{'Rel'} eq '<=') &&
+ # conflicted-with package is on new list
+ $params->{'New'}->{$self->{'Name'}}->{'Package'}) {
+ # If there's a dependency from the conflicted-with package to
+ # us, this would create a cycle :-(
+ if (exists($params->{'New'}->{$self->{'Name'}}->{' _Depends'}->{$name})){
+ warn "Cannot order for conflict of $name with $self->{'Name'}\n";
}
+ else {
+ push(@{$params->{'Package'}->{' _Order'}}, "$self->{'Name'} $name");
+ }
+ }
}
else {
if ($params->{'New'}->{' _Provided'}->{$self->{'Name'}}) {
@@ -578,7 +589,7 @@
for (@providers) {
if ($params->{'New'}->{$_}->{'Package'}) { # Aha! new package
push(@{$params->{'Package'}->{' _Order'}},
- "$_ $params->{'Package'}->{'Package'}");
+ "$_ $name");
}
}
}
--OJJBR7lUBv
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--
All processes are impermanent. When one sees this with understanding,
then one is disillusioned with the things of suffering. This is the
Path of Purification. 277
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--OJJBR7lUBv--
Reply to: