Forwarded message from Roman Hodek, 15:02:40 Thu,6 November 1997
--YvBZsyXiqq
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--YvBZsyXiqq
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 JAA00862
for <srivasta@tiamat.datasync.com>; Thu, 6 Nov 1997 09:56:02 -0600
Received: from mail.datasync.com
by tiamat.datasync.com (fetchmail-4.3.2 POP3 run by srivasta)
for <srivasta@tiamat.datasync.com> (single-drop); Thu Nov 6 09:56:07 1997
Received: by osh5 for srivasta
(with Cubic Circle's cucipop (v1.21 1997/08/10) Thu Nov 6 09:56:03 1997)
X-From_: rnhodek@immd2.informatik.uni-erlangen.de Thu Nov 6 09:02:53 1997
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 SMTP id JAA21489 for <srivasta@datasync.com>; Thu, 6 Nov 1997 09:02:51 -0600
Received: from faui22c.informatik.uni-erlangen.de by immd2.informatik.uni-erlangen.de with SMTP (5.64+/7.3h-FAU)
id AA18652; Thu, 6 Nov 97 16:01:52 +0100
Message-Id: <9711061501.AA18652@faui21.informatik.uni-erlangen.de>
In-Reply-To: <[🔎] 87g1paqf7e.fsf@tiamat.datasync.com> (srivasta@datasync.com)
Reply-To: Roman.Hodek@informatik.uni-erlangen.de
X-Filter: mailagent [version 3.0 PL58] for srivasta@tiamat.datasync.com
From: Roman Hodek <rnhodek@faui22c.informatik.uni-erlangen.de>
To: srivasta@datasync.com
Subject: Re: Another little bug in pkg-order
Date: Thu, 6 Nov 1997 15:02:40 GMT
Hi Manoj!
> The only dependency checks made by the library are the ones
> explicitly requested; so I think in this case that is the set of
> packages to be installed.
Yup. I currently do
foreach ( @list ) {
$candidates->check_relations( Consistent => 1,
Installed => $installed,
Field => $_ );
}
where @list is (Pre-Depends Depends Conflicts) plus Recommends and/or
Suggests if requested by options.
> I think maybe you should look at creating the dependencies and
> checking them for the installed packages as well (give the same list
> twice as arguments). I hope this won't make things too slow. Maybe
> keep tags of whether the installed or the new list is changed, and
> recheck as needed?
I already recheck only if I made changes to one of the lists. And the
only thing where a check on installed packages might be needed is if a
installed package is selected for removal (for conflict management).
So I could save the dependency stuff on installed packages as long as
no packages are removed.
I think I need to do
foreach ( qw(Pre-Depends Depends) {
$installed->check_relations( Consistent => 1,
Installed => $installed,
Field => $_ );
}
I'm think I can omit Conflicts, because removing something can't cause
a new conflict, right? Recommends/Suggests are optional as above.
Do I need to run result_as_string on $installed then, too, or are the
results returned via $candidates?
> In the Deity code I'm starting to work on We are considering
> ordering all interactions with dpkg; that means purges and removes
> as well. For the most part we put the removes first in the list
> (even if it fails, the package is marked for removal; and shall be
> removed when the conflicting package is tried to be installed).
This seems ok to me. But does it really work that way (i.e., tested?)
> The problem I see is if there is an old package A, superceded by a
> new package B, and a new package C conflicts with A and not B. In
> this case, B should be installed ahaead of C, but there is no
> explicit relationship between B and C. Hmmm. This requires thought.
The conflict between C and A should trigger some special action. It
would be a fatal error anyway if it couldn't be solved somehow. The
special action could be looking for ways that one of the two packages
disappear. In your example, this would be that B is going to replace
A. For this, you can introduce some special relation between A and B
("replace solves conflict") that also forces them to end up in
separate runs.
But my problem was of different nature, I think. It was that newer
libc6 lib packages conflicted with earlier libc5 versions (because
these still didn't install in libc5-compat), but the updated libc5
version was installed in a later run. This shouldn't happen, the libc5
package update should happen in the same or an earlier run. (At least
I hope in the same run is sufficient; haven't tried...)
But I currently do ordering with the following code:
# don't care about critical errors, packages with --force options
# always have them...
$installed->set_fatal_failure_on_types( 'Type List' => ' ' );
$candidates->set_fatal_failure_on_types( 'Type List' => ' ' );
# build package ordering
$candidates->order( Field => "Pre-Depends" );
$candidates->order( Field => "Depends" );
my $order_string = $candidates->get_ordering();
my $order_str2 = $candidates->insert_breaks('Ordered List' => $order_string);
Is it possible to call the order method for field Conflicts?? (I.e.,
$candidates->order( Field => "Conflicts" )) Or does this produce
nonsense?
Roman
--YvBZsyXiqq
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--
Date: 16 Apr 90 15:58:21 GMT From: merlyn@iwarp.intel.com (Randal
Schwartz) $_='987;s/^(\d+)/$1-1/e;$1?eval:print"Just another Perl
hacker,"';eval
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
--YvBZsyXiqq--
Reply to: