Re: Another little bug in pkg-order
Hi,
>>"Roman" == Roman Hodek <rnhodek@faui22c.informatik.uni-erlangen.de> writes:
Roman> I think I need to do
Roman> foreach ( qw(Pre-Depends Depends) {
Roman> $installed->check_relations( Consistent => 1, Installed =>
Roman> $installed, Field => $_ );
Roman> I'm think I can omit Conflicts, because removing something
Roman> can't cause a new conflict, right? Recommends/Suggests are
Roman> optional as above.
Right.
Roman> Do I need to run result_as_string on $installed then, too, or
Roman> are the results returned via $candidates?
Hmm. The results are returned in the ' _Results' object
associated with each packaeg. result_as_string just collates all
results for all packages as a giant string, which can then be printed
out. There are other routines that merely count the errors (caled,
for some reason, check); I think you should look at pkg-order where I
use the call. So, do the depends as above, and then call check to see
if there was an error. What you do then is upto you ;-)
>> 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).
Roman> This seems ok to me. But does it really work that way (i.e.,
Roman> tested?)
Only informally (observed behaviour when calling dpkg manually).
>> 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.
Roman> The conflict between C and A should trigger some special
Roman> action. It would be a fatal error anyway if it couldn't be
Roman> solved somehow. The special action could be looking for ways
Roman> that one of the two packages disappear. In your example, this
Roman> would be that B is going to replace For this, you can introduce
Roman> some special relation between A and B ("replace solves
Roman> conflict") that also forces them to end up in separate runs.
Yes, but all these hueristics are hard ;-)
Roman> But my problem was of different nature, I think. It was that
Roman> newer libc6 lib packages conflicted with earlier libc5 versions
Roman> (because these still didn't install in libc5-compat), but the
Roman> updated libc5 version was installed in a later run. This
Roman> shouldn't happen, the libc5 package update should happen in the
Roman> same or an earlier run. (At least I hope in the same run is
Roman> sufficient; haven't tried...)
Umm, your old libc5 packages are of type A, you new libc5
packages are type C, and your new libc6 packages are type B. Type C
(new libc5 packages) should replace type A (old libc5 packages)
before type B (new libc6 packages) are installed. This requires some
thought for a general solution.
Roman> Is it possible to call the order method for field Conflicts??
Roman> (I.e., $candidates->order( Field => "Conflicts" )) Or does this
Roman> produce nonsense?
No, I don't think you can order based on conflicts; a conflict
means that the two packages should not be installed together at any
point; just running depends on that foeld should be enough during the
consistency checking phase.
manoj
--
"All Marxists, basically, are reactionaries, yearning for the
Oriental despotisms of pre-Hellenic times, the neolithic culture that
preceded the rise of self-consciousness and egoism." Robert Anton
Wilson, writing as "Justin Case".
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
Reply to: