i keep *trying* to move from portupgrade to portmaster
in [Ports]
|
From: Adam Vande More on 6 Aug 2010 20:46 On Fri, Aug 6, 2010 at 5:11 PM, Doug Barton <dougb(a)freebsd.org> wrote: > On 08/06/2010 15:03, Adam Vande More wrote: > > for pkg in /var/db/pkg/* ; do > pkg_create -b $pkg > done > Yes, that is basically what I'm talking about, my script is a little fancier now, prompts for directory with a default if you just want to use a standard location. Also can create directory or clean out an existing one. > > have a python script that does this for me, but it would be easy enough > > to use sh as well. I do this because there have been too many times > > something has broken during a port upgrade run and I need to revert > > immediately and fix later. I realize the backup package feature sort of > > does the same thing, but reconciling the pre- and post- updates is a > > tough thing for me. Having a user defined directory all currently > > installed ports can be put in is much easier to work with IMO. I know of > > other people doing similar things because I shared my script on > > questions- and got a few responses awhile ago. > > It sounds like you want to add the option(s) for "create and keep a > backup package of an installed port" and/or "create a package of the new > port" either to your command line, wrapper script, or a portmaster rc > file. You could use the command line above to create an up to date > repository of your currently installed packages, and the 2 options above > would both make sure you can back out an update and keep your local > package repo up to date automatically. > Yeah, I can and do this via a wrapper, it's certainly works well enough. Maybe some triggers users could set to run pre- and post- postmaster runs? But as you you say, easy enough to do with a wrapper. I don't think pkg_create preserves the config files user edited, which > is the precious stuff, but it preserves a lot of useless stuff. > The following python script by Cyrille Szymanski may be more useful: > http://www.lpthe.jussieu.fr/~talon/pkg_save.py<http://www.lpthe.jussieu.fr/%7Etalon/pkg_save.py> > It keeps the config files and the shared libraries. Yes that's a great script for managing individual packages. Mine is much simpler and there is no need for backing up shared libs since your dealing with a package "snapshot". I also backup /usr/local/etc separately which is where all the package config files I care about live. Also -- Adam Vande More _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: jhell on 7 Aug 2010 02:22 On 08/06/2010 17:26, Doug Barton wrote: >> and force creation of whatever you have on the system already? > Not sure what this means, can you explain it in more detail? No matter what the state of a package is I feel deeply that when making a backup package, that should not fail because of a missing file that might have been caused by a incorrect pkg-plist or whatever. Most of the times I have noticed backup package creation fail was caused by tar(1) or other tools not being able to stat a file or directory. For instance: Creating bzip'd tar ball in '/exports/packages/GraphicsMagick-1.1.15_3,1.tbz' tar: lib/ImageMagick-6.6.2/modules-Q16/coders/djvu.la: Cannot stat: No such file or directory tar: lib/ImageMagick-6.6.2/modules-Q16/coders/djvu.so: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 And this has left the GraphicsMagick package incomplete. I would believe that portmaster is probably dealing with the same problem. > >> > Configuration option to email the output of upgraded packages and their >> > pkg-message or a similar option to just log to a file? > The ability to log actions to a file is already in the dev version in > svn. You have to specify PM_LOG in your rc file. I want to see how that > goes first before I consider adding a command line option for it. I > don't anticipate adding e-mail functionality to portmaster, that sounds > like something that should be done in a wrapper script, along with > PM_LOG. (Although, there was a meme from the early days that no Unix app > is complete until it grows the ability to do e-mail, so you never know ...) > I agree with you on this. Seeing as PM_LOG will be there that makes it much easier to deal with. -- jhell,v _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: jhell on 7 Aug 2010 02:23 On 08/06/2010 18:03, Adam Vande More wrote: > On Fri, Aug 6, 2010 at 4:26 PM, Doug Barton <dougb(a)freebsd.org> wrote: > >> I need to add an option for this, but it will likely be an "expert" >> option that you can set in the rc file. The theory is that package >> creation failure should be a rare thing, and since portmaster has no way >> to know what packages are really critical to any given system it treats >> inability to safely recover from an upgrade failure as a critical error. >> However, having the ability to disable this is an oft-requested feature, >> I just haven't gotten to it yet. >> >> I actually took a look at the code in this area last night with an eye >> towards creating this option, I'll see if I can get it done for the next >> release. >> > > While your in the mood for for taking portmaster suggestions, I think an > option to backup all currently installed packages would be useful. I have a > python script that does this for me, but it would be easy enough to use sh > as well. I do this because there have been too many times something has > broken during a port upgrade run and I need to revert immediately and fix > later. I realize the backup package feature sort of does the same thing, > but reconciling the pre- and post- updates is a tough thing for me. Having > a user defined directory all currently installed ports can be put in is much > easier to work with IMO. I know of other people doing similar things because > I shared my script on questions- and got a few responses awhile ago. > Just for reference. Doug B. has already touched on this. #!/bin/sh trap 'exit 1' 2 _pkg_bld(){ cd /exports/packages for package in `ls /var/db/pkg |sed 's/pkgdb.db//'`; do echo "Building package: $package" pkg_create -v -b $package >>pkg_bld.log 2>&1 done } _pkg_bld I never did add a test to see if the package was already there but then again I used this before extreme situations that the upgrades would span the whole ports tree. -- jhell,v _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Doug Barton on 7 Aug 2010 22:40 On 08/06/2010 14:03, Doug Barton wrote: > I plan to commit the update very soon, hopefully this weekend. et voila! -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Dominic Fandrey on 12 Aug 2010 13:33
On 06/08/2010 23:26, Doug Barton wrote: > On 08/06/2010 04:34, jhell wrote: > >> Do not prompt for a backup package creation failure > > I need to add an option for this, but it will likely be an "expert" > option that you can set in the rc file. The theory is that package > creation failure should be a rare thing, and since portmaster has no way > to know what packages are really critical to any given system it treats > inability to safely recover from an upgrade failure as a critical error. > However, having the ability to disable this is an oft-requested feature, > I just haven't gotten to it yet. Maybe you could treat pkg_create's return value 2 special, that's what pkg_upgrade does. Return value 2 means that creating a backup was successful, but incomplete because of missing files. All the more reason to replace the package in my opinion. It's the most common case and it has no influence on portmaster's ability to return the original state if something goes wrong, so there's really no need to treat it differently from return value 0. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |