[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Forwarded message from Roman Hodek, 16:45:10 Mon,26 January 1998



--kI0EmnLSQs
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 JAA17674
	for <srivasta@tiamat.datasync.com>; Mon, 26 Jan 1998 09:55:15 -0600
Received: from mail.datasync.com
	by tiamat.datasync.com (fetchmail-4.3.5 POP3)
	for <srivasta@tiamat.datasync.com> (single-drop); Mon, 26 Jan 1998 09:55:15 CST
Received: by osh5 for srivasta
 (with Cubic Circle's cucipop (v1.21 1997/08/10) Mon Jan 26 09:55:13 1998)
X-From_: rnhodek@faui21.informatik.uni-erlangen.de  Mon Jan 26 09:45:19 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 JAA27667 for <srivasta@datasync.com>; Mon, 26 Jan 1998 09:45:14 -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 QAA08458;
	Mon, 26 Jan 1998 16:45:12 +0100 (MET)
Received: (from rnhodek@localhost)
	by faui22c.informatik.uni-erlangen.de (8.8.8/8.8.8/cl-FAU) id QAA13872;
	Mon, 26 Jan 1998 16:45:10 +0100 (MET)
Message-Id: <199801261545.QAA13872@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: Conflict ordering in pkg-order
Date: Mon, 26 Jan 1998 16:45:10 +0100 (MET)


Hi Manoj!

I've now attempted to fix the last thing in pkg-order that doesn't
work for me (or better: dftp): The implicit dependencies that can be
introduced by Conflicts: xx (<< v), as they happen usually on libc5 ->
libc6 library upgrades.

The patch below is experimental. I just tried to get this in, but I
may have made errors, since I still don't know all pkg-order internals
very well :-) So please check this before applying it... :-)

For the following, assume a typical example:

  Package: libfoo1
  Version: 1.0
  Depends: libc5

is installed, and the following are candidates:

  Package: libfoo1
  Version: 1.1
  Depends: libc5
  
  Package: libfoo1g
  Version: 1.1
  Depends: libc6
  Conflicts: libfoo1 (<< 1.1)

  Package: libfoo1g-dev
  Version: 1.1
  Depends: libc6-dev, libfoo1 (= 1.1)

Since libfoo1g conflicts with earlier versions of libfoo1, the upgrade
for it must be installed before libfoo1g. This is two-part: libfoo1
must not be after a break between it and libfoo1g, and it must be
before libfoo1g if they're installed in the same dpkg run. Means: It
is sufficient if we pretend that libfoo1g depends on libfoo1.

First thing I do is not to return 'Unknown' from Dependency::do_depend
if no conflict is found on a Conflicts:, but the conflicted-with
package is on the new list. Instead I return 'Noconflict'. The
background: If still 'Unknown' would be returned, Dependency::depend
would interpret this as the installed list had to be searched, too.
And then a real conflict is found there... Seems that this is the
deeper reason why I had to remove to-be-upgraded packages from the
installed list... :-) (or to mark them somehow).

Note that 'Unknown' is still returned if the package mentioned in the
Conflicts: field is not found in the package list, so that the install
list is still checked for packages that aren't installed (upgraded).

I hope I got the case handlings in Dependency::depend right :-) I let
do nothing in all cases of 'Noconflict', which should be the same as
before for 'Unknown'.

Next thing: Dependency::order checks for Type eq 'Conflicts' (which
are allowed now in List::order). If so, and it's a versioned conflict,
and the relation is << or <=, and the conflicting package is on the
candidates list, a dependency (as said above) is faked.

I see that the conditions above aren't optimal yet. The faked
dependency is introduced for all xx (<< v) type conflicts, not only
for those where the conflict is really only avoided by the upgrade of
package xx. But for that, I'd have to search the installed list, too,
if there's a package xx with version << v, and xx >= v is on the
candidates list. This seems a bit much of trouble... :-) (I'd need the
installed list as parameter, and I'd have to do two times dpkg
--compare-versions.)

On the other hand, it doesn't hurt much if the dependency is faked
though it isn't necessary. Or does it hurt? Don't think so...

The so-patched pkg-order works fine on the simple example case above.
I.e. no conflict reported anymore (though the installed libfoo1 hasn't
been marked or deleted), and the order is correct. I haven't check a
bigger test case yet, though...

Roman

------------------------------------------------------------------------------
--- Dependency.pm~	Mon Jan 26 13:34:46 1998
+++ Dependency.pm	Mon Jan 26 16:10:28 1998
@@ -283,7 +283,11 @@
       }
       last;
     };
-    
+
+    /Noconflict/ && do {
+      # no action...
+      last;
+    };
 
     /Success/ && do {
       $params->{'New'}->{' _Targets'}->add
@@ -476,7 +480,7 @@
 	
 	if ($return_val) {        # No match
 	  if ($self->{'Type'} =~ /Conflict/) {
-	    $ret = 'Unknown';             # no conflict
+	    $ret = 'Noconflict';
 	  }
 	  else {
 	    print STDERR "\tDEBUG: type $self->{'Type'} Failed\n"
@@ -521,7 +525,7 @@
   if($ret =~ /Conflict/  && $Replaces) {
     my $ret_val = $Replaces->match($self);
     if ($ret_val  eq 'Yes') {
-       $ret = 'Unknown'; 
+       $ret = 'Noconflict'; 
     }
     
   }
@@ -551,21 +555,31 @@
   croak("Required parameter New package list absent") 
     unless $params->{'New'};
 
-  if ($params->{'New'}->{' _Provided'}->{$self->{'Name'}}) {
-    # Pesky multiple providers
-    push (@providers, 
-	  split(/,/, 
-		$params->{'New'}->{' _Provided'}->{$self->{'Name'}}));
+  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'}");
+      }
   }
   else {
-    push (@providers, $self->{'Name'});
-  }
+    if ($params->{'New'}->{' _Provided'}->{$self->{'Name'}}) {
+      # Pesky multiple providers
+	push (@providers, 
+	      split(/,/, 
+		    $params->{'New'}->{' _Provided'}->{$self->{'Name'}}));
+    }
+    else {
+      push (@providers, $self->{'Name'});
+    }
 
 
-  for (@providers) {
-    if ($params->{'New'}->{$_}->{'Package'}) { # Aha! new package
-      push(@{$params->{'Package'}->{' _Order'}}, 
-	   "$_ $params->{'Package'}->{'Package'}");
+    for (@providers) {
+      if ($params->{'New'}->{$_}->{'Package'}) { # Aha! new package
+        push(@{$params->{'Package'}->{' _Order'}}, 
+	     "$_ $params->{'Package'}->{'Package'}");
+      }
     }
   }
 }
--- List.pm~	Mon Jan 26 13:34:40 1998
+++ List.pm	Mon Jan 26 16:33:09 1998
@@ -593,8 +593,6 @@
   my $name;
   
   croak("Missing Parameter Field") unless $params{'Field'};
-  croak("Can't order packages based on conflicts!\n")
-    if $params{'Field'} eq 'Conflicts';
   
   foreach $name (sort keys %$self) {
     my %Arguments;
--- /usr/bin/pkg-order~	Mon Jan 26 14:47:21 1998
+++ /usr/bin/pkg-order	Mon Jan 26 15:19:23 1998
@@ -301,6 +301,8 @@
   $candidates->order('Field' => 'Pre-Depends');
   # Order Dependencies
   $candidates->order('Field' => 'Depends');
+  # Order Conflicts
+  $candidates->order('Field' => 'Conflicts');
 
   ######################################################################
   #                    Phase Five: Do ordering                         #


--kI0EmnLSQs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


-- 
 We turn toward God only to obtain the impossible.
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

--kI0EmnLSQs--


Reply to: