Problems with +CONTENTS being messed up by pkg_delete -f

[Doug Barton]

I'm dropping -hackers since this is a ports issue.

Stephen Montgomery-Smith wrote:
> 
> If you "pkg_delete -f" a package and then install the port again (but
> after it has been bumped up a version), then the +CONTENTS of ports that
> require the original port will be incorrect.  This apparently messes up
> programs like portmanager.  There is a sense in which one should never
> do "pkg_delete -f" and expect /var/db/pkg to keep its integrety 

Not "a sense," you simply shouldn't expect things to work properly if
you do this. The -f flag _means_, "do this even if it's a bad idea."

Now that said, before I wrote portmaster I used to do this all the
time, and almost never had a problem. I added a routine to clean up
the +CONTENTS and +REQUIRED_BY files to portmaster almost as an
afterthought, and I'm still ambivalent over when it's right to delete
stuff from +CONTENTS, and when it isn't.

The good news is that if you have weird stale stuff in +CONTENTS files
portmaster will try to fix it for you at best, and at worst it won't
choke on it.

> on the other hand this is exactly what "make deinstall" does.

I'm not sure I see the relevance of this bit.

> My feeling is that the integrety of /var/db/pkg should be maintained
> across a "make deinstall" and subsequent "make install" of a bumped
> version of the port.

Can you define what you mean by integrity?

> This is my suggestion.  When a "pkg_delete -f" is executed, it looks
> through +REQUIRED_BY of the port it is going to delete,

How do you know that file is up to date? :)

> and modifies the
> +CONTENTS file of each of them, replacing lines like
> @pkgdep xineramaproto-1.1.2
> @comment DEPORIGIN:x11/xineramaproto
> 
> to maybe something like
> @comment DELDEPORIGIN:x11/xineramaproto

My gut feeling is that this is overkill. I'll have to give it some
thought though.

> ("deleted dependency origin").  A subsequent "make install" of
> x11/xineramaproto should look through the +CONTENTS of all entries in
> /var/db/pkg and change these lines to something like
> 
> @pkgdep xineramaproto-1.1.3
> @comment DEPORIGIN:x11/xineramaproto
> 
> A further benefit of this approach is that one could also accurately
> reconstruct the +REQUIRED_BY of the port just reinstalled - right now
> this is left empty and thus inaccurate.

Doing what you suggested isn't necessary to rebuild the +REQUIRED_BY
file.

What portmaster does (assuming we are upgrading a port that is
depended on) is:

1. Build the new version of the port
2. grep for the short name of the port in existing +CONTENTS files and
save the sorted result
3. sort the +REQUIRED_BY file and compare the two
4. If they match, we proceed, if not we give the user the opportunity
to correct the +REQUIRED_BY file
5. Once that is sorted out, we pkg_delete -f the old and install the
new version of the port
6. Update the pkgdep line in each +CONTENTS file for the ports listed
in the new +REQUIRED_BY file
7. Install the new +REQUIRED_BY file

In this way everything gets updated from scratch, so you're left with
stuff in a consistent state. In my experience, you have to do at least
that much work to make sure that you leave everything better than you
found it, and if there are missing dependencies in +REQUIRED_BY you
pretty much have to give the user options to fix it because it's  hard
to get all the edge cases right programmatically.

Now portmaster can also fix this for you if you pkg_delete -f
something by hand, and then use portmaster to install the new version.

What portmaster does _not_ do at this time, and one of the things I'm
ambivalent about adding is what you actually posted about; detecting
duplicate entries with the same DEPORIGIN and reducing them down to
one entry. I've resisted adding that because it's not particularly
easy (or fast, which I'm more interested in) to do that in sh, having
duplicates doesn't hurt anything (as far as I've ever been able to
tell), and the problem will be erased the next time the user rebuilds
the port that has the dependency. If someone feels strongly that
fixing this is important, I can look at this again, but my gut feeling
is that it isn't a very important problem.

Now if it's true that these duplicates do break portmanager, then it
does become more important to me, since I don't want to do anything in
portmaster that will negatively impact the ability to use a different
ports management tool. So if we get a definitive answer on this I'll
definitely take another look.

Doug

-- 

    This .signature sanitized for your protection