Re: Ports updating... Good ways?
Jim Weeks: >On Thu, 8 Feb 2001, David Bushong wrote: >> I'll try to put a "cleanup" mode in one of these days, but it's rather nasty, >> since basically you have to: >> >> pkg_delete all of the versions (including the most recent), pkg_delete all >> of the programs that depended on older versions, reinstall/rebuild the most >> recent version, then rebuild the dependent packages. > >You don't really have to do this. You can remove the info files for the >old versions from /var/db/pkg/. For instance, if you have checked >pkg_info and found you have two versions of zip ie zip-2.3 and zip-2.2, >simply rm -r /var/db/pkg/zip-2.2 Disagree. Consider that zip-2.2 had added a file /usr/local/where/ever which is no longer part of zip-2.3. Now you want that one cleaned up as well, don't you? Having two versions of one port installed is generally a Bad Thing as it may result in orphan files. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Ports updating... Good ways?
One way to make it easy to keep ports updated is to only cvsup the ports you need. Then you build from the top. Cvsup has pattern matching so the following code doesn't need version number suffixes. You will end up with the latest versions. I did this. #!/bin/gross_pseudocode $suplist=portpattern_1 \ portpattern_2 \ Mk and friends \ portpattern_3; cvsup $suplist cd /usr/ports make install I deleted the script some time ago. The method worked pretty well. The only problem is when a particular port added a new dependency (KDE was bad for this). The code above is gross, but the idea worked. The cool part was the all of the installing and building went pretty well. If you put your script ona floppy, then you can rebuild all of the /usr/local stuff on some other machine and come up with a near mirror. Thank you, Jason C. Wells To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Ports updating... Good ways?
What about extending "make" so that it is possible to do the following: $ cd /usr/ports/foo/bar $ make update "make" would then automatically deal with updating dependencies for that specific port, remove the old version and build the new one. I know this thread is mostly about updating all your ports at once, but this seems to be a good start. Using "make" in such a way ties in nicely with the current use of the ports system in my opinion. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Ports updating... Good ways?
An important note I forgot to mention: pkg_upgrade does not deal well with inconsistent installed packages. Make sure your packages are neat and tidy before you start using it. What does that mean? Mainly, make sure you don't have multiple installed versions of the same version of a piece of software. Having ncftp2 and ncftp3 both installed is fine, but having gtk-1.2.8, gtk-1.2.7, and gtk-1.2.6 installed is not a terribly good idea. I'll try to put a "cleanup" mode in one of these days, but it's rather nasty, since basically you have to: pkg_delete all of the versions (including the most recent), pkg_delete all of the programs that depended on older versions, reinstall/rebuild the most recent version, then rebuild the dependent packages. Whee. --David Bushong P.S. Screwed up my .muttrc earlier, so I'm "Timus" On Wed, Feb 07, 2001 at 10:41:18PM -0800, David Bushong wrote: > pkg_version -c, while better than nothing, has quite a few problems, most > significant of which is dependency ordering (making sure that a library that, > say, "xv" depends on gets upgraded before "xv" itself. > > I've been working on a decent upgrade script for the past few months, and now > seems as good a time as any to have people try it out. > > It's called "pkg_upgrade", and you can get it off of: > http://bushong.net/dave/sw/ > > Requirements: > > * At minimum, the INDEX file from the ports tree; better yet is an actual > ports tree (/usr/ports) > * The perl LWP modules (install /usr/ports/www/p5-libwww if you don't have it) > > Features: > > * will usage existing packages if they exist, and optionally build them if > they don't; great for an NFS mounted ports/packages directory > * will try to fetch packages before building > * handles dependencies correctly > * handles the "disappearing library file" problem (new version of lib package > doesn't provide lib that another installed package needs) > * other stuff i can't remember > > Usage is "pkg_upgrade -h" > > For a summary of what it _would_ do, were you to let it, try: > > pkg_upgrade -al > > Comments/feedback/code/replacement better package system for FreeBSD ;) > welcome. > > --David Bushong > > On Wed, Feb 07, 2001 at 10:18:14PM -0800, Mike Harding wrote: > > > > pkg_version -c | sh > > > > often works but you will probably want to spool it to a file. > > > > - Mike H. > > > >Date: Thu, 08 Feb 2001 13:48:07 +1100 > >From: Kal Torak <[EMAIL PROTECTED]> > >X-Accept-Language: en > >Content-Type: text/plain; charset=us-ascii > >Sender: [EMAIL PROTECTED] > >X-Loop: FreeBSD.ORG > >Precedence: bulk > > > >Hiyas, > > > >Just wanted to see if anyone has some good ways of updating installed > >ports... > > > >It would be good if you could update your installed ports as easily > >as the base system, like some sort of script that worked out all the > >dependencies and updated everything :) > > > >So anyone have a better way than slowly doing it by hand? > > > >Cheers! > >Kal. > > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] > >with "unsubscribe freebsd-stable" in the body of the message > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Ports updating... Good ways?
[moved to -ports] If memory serves me right, Mike Harding wrote: > > Well, just to defend myself... > > I find that pkg_version -c is a useful tool for helping me do > upgrades. I do put the result in a file and do the appropriate thing. ^^^ That was my point. You do *not* want to blindly execute the output of "pkg_version -c". I'm about --><-- this far away from crippling the output of "pkg_version -c" so that it can't be run without editing. People don't realize how dangerous this is; like it can actually render a system unusable. (I know, it happened to a good friend of mine.) > I do agree that something better is needed - one issue is the way that > the ports system tracks dependencies. If the dependency was tracked > in the dependent port rather than the other way around (in other > words, the ports notes that it needs the library rather than the > library noting that it is needed by another port) then the whole > upgrade issue would be simpler as you could actually make multiple > scans over the dependencies until everything was in order. Right now > the dependency information is 'lost' if you ugrade a library. Yeah. I posted a brain-dump of what I think is needed to -ports sometime earlier this week or last week. It's actually not that hard now that we have the "port origin" information for installed ports. The hard part is dealing with all the edge cases. I think that it would be a great project for someone to hack on bsd.port.mk to create a "make upgrade" target. But it has to be extremely conservative in the face of pathologies. > Also, > say, upgrading X with the current system will cause huge amounts of > things to be rebuilt - these ports depend on X but not the version. I think that XFree86 is handled as a special case, but your point is well-taken. Bruce. PGP signature
