Problems with +CONTENTS being messed up by pkg_delete -f

[Alexander Leidinger]

Quoting tmseck-lists at netcologne.de (Thomas-Martin Seck) (Fri, 20 Jul 2007 19:54:06 +0200 (CEST)):

> * Alexander Leidinger <Alexander at leidinger.net> [gmane.os.freebsd.devel.ports]:
> 
> > Quoting Robert Noland <rnoland at 2hip.net> (Thu, 19 Jul 2007 13:31:42 -0400):
> > 
> >> Ok, so the issue that I hope to address is not really a "portmanager"
> >> issue.  The original version of package-depends always listed the
> >> current version (from ports) in the +CONTENTS file.  When that list was
> >> passed to sort -u, you ended up with a single dependency for each
> >> origin.
> >> 
> >> The new way it takes each direct dependency and adds those, then
> >> recursively parses the +CONTENTS file of each of those and adds those
> >> entries and finally passes the whole thing to sort -u.  This allows for
> >> multiple dependencies with the same origin to be listed in the +CONTENTS
> >> file.
> >> 
> >> As an example... port a depends on b and c.  Port c has a version bump
> >> and is updated but technically b doesn't require an update.  Now if port
> >> a is updated it will get the current version of c and also the old
> >> version of c from b.
> > 
> > Ok, I see the problem (in case b depends on c too). This is only an
> > issue if you do this by hand instead of using portupgrade (or something
> > else), as those tools should correct the dependency in port b to the
> > new version of c. If they don't do it, it's a bug in those tools.
> 
> Oh not at all. This will also happen if you install dependencies via
> packages when these packages' dependencies do not exactly match what you
> have presently installed. 
> 
> Example:
> 
> package a-1.0 has a recorded dependency on b-1.0. Meanwhile, b got
> upgraded to 1.0_1.
> You have b-1.0_1 installed locally and then install port c which depends
> on a and use a's package in order to save build time (imagine a being
> something in the firefox/xorg-libs range with USE_PACKAGE_DEPENDS set in
> your make environment). Hilarity ensues. The old algorithm could recover
> from this I guess.

Sort of. There would still be a wrong dependency in the db (for port a,
but not for port c).

As for the current algorithm this only leads to listing a dependency
more than once. Normally this is catched by the sort in PKG_ARGS, but
as only the origin is the same and not the version number, this fails.
To fix it, we can change the sort invocation to include "-t : -k 2".
This does fix this issue, but also changes the final sorting order
(sorted for origin, and not for package name). Is this an issue?

Here's a visualisation.

Old sort invocation:
  printf 'png-1.2.18:graphics/png\nperl-5.8.8:lang/perl5.8\nperl-5.8.8_1:lang/perl5.8\n' | sort -u

Result:
perl-5.8.8:lang/perl5.8
perl-5.8.8_1:lang/perl5.8
png-1.2.18:graphics/png

New sort invocation:
  printf 'png-1.2.18:graphics/png\nperl-5.8.8:lang/perl5.8\nperl-5.8.8_1:lang/perl5.8\n' | sort -u -t : -k 2

Result:
png-1.2.18:graphics/png
perl-5.8.8:lang/perl5.8


Attached is the patch for this and the bug when a port has no origin
recorded (and the fix for the comment regarding the name of the
actual-package-depends target). I haven't tested this much, maybe
someone can give it a try in the case where a port has no origin
recorded and in the case which is discussed in this thread. If
everything is fine and portmgr doesn't object to the change of the
final order of the dependencies as recorded in the package, I will
submit this for an experimental run on the ports build cluster.

> It looks like one is forced to repair the package db with external tools
> everytime one does not install from source and from scratch.

This was the case before (sort of), but it was not that obvious as now.

Bye,
Alexander.

-- 
Time is the most valuable thing a man can spend.
		-- Theophrastus
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bsd.port.mk.diff
Type: text/x-patch
Size: 1602 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20070721/dd6cc53c/bsd.port.mk.bin