Re: housecleaning and portupgrade question
in message [EMAIL PROTECTED], wrote Jason Hunt thusly... Personally I have always just installed the newer version of a port on-top of the older one. Then I go through the package database and fix the dependencies ... After fixing the dependencies I just remove the directory for the old package and it's uninstalled. yuck, that's one unsanitary way to keep ports updated. I don't know if this is the best way to go about maintaining packages, and I realize that lots of unused/old files are being left around, but FWIW I have not run into any problems. Maybe someone has better advice? portupgrade usage advice has been repeated many times on various freebsd mailing lists; i don't use it for that purpose. this is not a better advice; this is how i upgrade ports w/ help of 2-3 script here there... - modify Makefile as appropriate. - in case of large port like mozilla, i fetch it first (make fetch); otherwise i don't bother w/i this. - in case of a port w/ interesting options, i extract it (make extract) to read the configure script. modify the Makefile as appropriate. - in case of unofficial patches for a port like mutt, i run make patch followed by application of external patches. - run make build (in the new ports directory). if it succeeds, delete the old port; may need to force the issue in case of a dependency port. when a dependency port is deleted, dependent port may or may not need to be rebuilt/reinstalled. - install the new port (make install). sometimes i also create a package (make package) which does the installation too. - file bug report when anything goes awry. log of output from the above process comes in handy at this time. - run make clean compress the logs (bzip2 -9 log) (if i remember). portupgrade ... know I sound like a prick here, but ...) if it's so good then why isn't it incorporated into the base system? many things which are so good are not in the base system, but most people need/use those things. search the -ports, -questions, perhaps -stable list w/ a query like freebsd base system ports include. - parv -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: housecleaning and portupgrade question
At 11:42 PM 10.24.2002 -0400, you wrote: On 24 Oct 2002, Kirk R. Wythers wrote: It looks to me like there is no reason for both aalib-1.4.r5 and aalib-1.4.r5_1. Seems that portupgrade does not cause this problem and is the prefered upgrade method There are numerous examples of this issue. My question is: what is the recommended way to delete an old version application x. This assumes of course that you are sure that it is not depended upon by some other app. Well you don't want to just 'pkg_delete -f' the older versions, since there will probably be a lot of files that got updated by the new version, which would cause a big mess. Personally I have always just installed the newer version of a port on-top of the older one. Then I go through the package database and fix the dependencies (I actually have a small script to do this for me). The package database is stored in the /var/db/pkg directory. Each port has it's own subdirectory, each of which contains a few files to describe the package, it's dependencies, files, etc. After fixing the dependencies I just remove the directory for the old package and it's uninstalled. I don't know if this is the best way to go about maintaining packages, and I realize that lots of unused/old files are being left around, but FWIW I have not run into any problems. Maybe someone has better advice? Also, I never really liked the idea of using portupgrade because it maintains a separate database and a completely different set of commands. I'm not saying portupgrade is bad since I really can't judge it, but (I know I sound like a prick here, but ...) if it's so good then why isn't it incorporated into the base system? I'm certainly open to new ideas, etc, but portupgrade seems like more of a bandaid to the original pkg database then fixing the problem (of upgrading ports and maintaining the database). Comments? Let me know if I'm way out of line. :) Well, you invited opinions. For a long time, I too stubbornly refused to try portupgrade, but once I did install it and use it, I found it to be a really slick set of tools and glad now that I use it. Just because something is not in the base system is not a valid reason for not using a good utility. There are lots of those that aren't in the base system. One really has nothing to do with the other, but if it helps someone to rationalize not trying something, it's as good as any other reason I guess. My reason was simply that I hadn't tried it and was not familiar with its fine abilities. Describing it as a bandaid indicates that one hasn't really tried it and speaks without any experience with the utility. It nicely cleaned up my messes left behind from installs over installs. I don't have the luxuary of the time to write a script or look for those many dependancies. The script has already been written in portupgrade and its tools. But, I understand reluctance to try something new -- that was me and my decision. Best regards, Jack L. Stone, Administrator SageOne Net http://www.sage-one.net [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: housecleaning and portupgrade question
On 24 Oct 2002, Kirk R. Wythers wrote: It looks to me like there is no reason for both aalib-1.4.r5 and aalib-1.4.r5_1. Seems that portupgrade does not cause this problem and is the prefered upgrade method There are numerous examples of this issue. My question is: what is the recommended way to delete an old version application x. This assumes of course that you are sure that it is not depended upon by some other app. Well you don't want to just 'pkg_delete -f' the older versions, since there will probably be a lot of files that got updated by the new version, which would cause a big mess. Personally I have always just installed the newer version of a port on-top of the older one. Then I go through the package database and fix the dependencies (I actually have a small script to do this for me). The package database is stored in the /var/db/pkg directory. Each port has it's own subdirectory, each of which contains a few files to describe the package, it's dependencies, files, etc. After fixing the dependencies I just remove the directory for the old package and it's uninstalled. I don't know if this is the best way to go about maintaining packages, and I realize that lots of unused/old files are being left around, but FWIW I have not run into any problems. Maybe someone has better advice? Also, I never really liked the idea of using portupgrade because it maintains a separate database and a completely different set of commands. I'm not saying portupgrade is bad since I really can't judge it, but (I know I sound like a prick here, but ...) if it's so good then why isn't it incorporated into the base system? I'm certainly open to new ideas, etc, but portupgrade seems like more of a bandaid to the original pkg database then fixing the problem (of upgrading ports and maintaining the database). Comments? Let me know if I'm way out of line. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: housecleaning and portupgrade question
in message [EMAIL PROTECTED], wrote Kirk R. Wythers thusly... aalib-1.4.r5 needs updating (port has 1.4.r5_1) aalib-1.4.r5_1 = up-to-date with port ... There are numerous examples of this issue. My question is: what is the recommended way to delete an old version application x. This assumes of course that you are sure that it is not depended upon by some other app. when you deinstall an old port, it's quite possible that files from new port will also be deleeted. in that case, you will need to re-install that new port. just be careful of -f (force) option of pkg_delete or pkg_deinstall. pay attention to any message which says along the lines of checksum mismatch, deleted anyway. in that case, see above. - parv -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
