Date: Wed, 18 Jul 2007 21:18:47 -0700 From: Garrett Cooper <youshi10@u.washington.edu> To: Stephen Montgomery-Smith <stephen@math.missouri.edu> Cc: ports@freebsd.org, Robert Noland <rnoland@2hip.net> Subject: Re: Problems with +CONTENTS being messed up by pkg_delete -f Message-ID: <469EE627.4000100@u.washington.edu> In-Reply-To: <469EC915.7010006@math.missouri.edu> References: <20070718154452.B3091@math.missouri.edu> <1184799050.33981.66.camel@rnoland-ibm.acs.internap.com> <469EC915.7010006@math.missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Montgomery-Smith wrote: > Robert Noland wrote: >> On Wed, 2007-07-18 at 15:56 -0500, 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 - on the other hand this is exactly what "make >>> deinstall" does. >>> >>> 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. >>> >>> This is my suggestion. When a "pkg_delete -f" is executed, it looks >>> through +REQUIRED_BY of the port it is going to delete, 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 >>> >>> ("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 >> >> Hrm, not quite what I had in mind... I don't want to misrepresent that >> a port was built against a newer version of a dependency. What I was >> hoping for would be that a port when reinstalled would not list both the >> current version of a dependency as well as a previous version of the >> same origin (which it aquired via the +CONTENTS of some other direct >> dependency). It should only list the currently installed version of >> that origin. >> >> That way it is still possible to determine that the interim port was >> built against an older version. I just want the +CONTENTS file to >> accurately list the versions that a given port was built against. > > I think I was not understanding your problem, nor how portmanager > works. Sorry about that. > > In general, I do really like how the present "actual-package-depends" > works, and so I would rather see this kept, and portmanager modified > to accomodate, rather than the other way around. > > Robert sent me some private emails about how "actual-package-depends" > was messing up portmanager. Probably he should send the problem > descriptions to the mailing lists, and maybe someone else could solve > them. I thought I had some ideas for quick fixes, but it seems I was > looking before I was leaping. I don't really have enough time right > now for long fixes, so someone else will have to figure it out. I > have to say that I simply don't use portmanager or portsinstall or > anything like that, so I don't know how they work. (Rather I use my > own home brew tools for doing the same thing, and since they are home > brew and only for my use, they don't need to get everything right > everytime, they can be simple, and they don't have to be at all > user-friendly.) > > Best regards, Stephen Stephen, I admire your willingness to help, but I believe that Robert should be the one detailing the problem not you. That way too much confusion doesn't get aroused on the list(s). I'm going to remove hackers@ from the CC list because this almost exclusively pertains to ports@. -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?469EE627.4000100>