Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
[If you follow up to this message please change freebsd-stable@ to freebsd-po...@. Thanks.] Ben Morrow wrote: > Since my machine has spent the last 48hrs or so rebuilding everything > that depended on jpeg-6b and python25 (it's a pretty old machine), I've > been wondering if an option to say '*don't* rewrite the dependencies of > other ports to refer to the new version' would be a good solution here. > > Normally this is a helpful thing to do, but when you're trying to > reinstall a few ports low in the dependency chain and then rebuild > everything that needs rebuilding it would be helpful to have the ones > that haven't been rebuilt still depend on the old (now deleted) package, > so they can be identified. That's an interesting idea, but with portmaster you can accomplish the same thing with the -r option. Just use the -R option on successive runs if the first one fails for some reason. > -r (and -Rr) don't help here, since lots of large ports depend on *both* > jpeg and python, and I was specifically trying to avoid rebuilding them > all twice. This is a situation (ports relying on 2 dependencies that both require complete rebuilds) that is not easy to program for. Fortunately it also does not come up very often. > AFAICT -r doesn't allow you to ask for two ports plus all > combined dependants at once. I ended up taking the pkg_info -R list for > both pkgs before the upgrade, sorting it into dependency order, and > stripping entries off the front every time something failed and I had to > restart, which is a little too manual for my taste :). (The list had to > be sorted, otherwise port A might depend on port B that came later in > the list, and when portmaster got to B in the list it would reinstall it > again unnecessarily.) For future reference you would have been better off if you had done 'sort -u' on the list then done 'portmaster `cat list`'. Portmaster would then do all the dependency sorting for you, and it will only rebuild each port on the list once. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Quoth Doug Barton : > > How about this? When the user has -[rf] but not -R, and there are flag > files present, ask if they should be cleared before beginning to do > anything. Otherwise (no -[rf]) ignore them. Sound good? Since my machine has spent the last 48hrs or so rebuilding everything that depended on jpeg-6b and python25 (it's a pretty old machine), I've been wondering if an option to say '*don't* rewrite the dependencies of other ports to refer to the new version' would be a good solution here. Normally this is a helpful thing to do, but when you're trying to reinstall a few ports low in the dependency chain and then rebuild everything that needs rebuilding it would be helpful to have the ones that haven't been rebuilt still depend on the old (now deleted) package, so they can be identified. -r (and -Rr) don't help here, since lots of large ports depend on *both* jpeg and python, and I was specifically trying to avoid rebuilding them all twice. AFAICT -r doesn't allow you to ask for two ports plus all combined dependants at once. I ended up taking the pkg_info -R list for both pkgs before the upgrade, sorting it into dependency order, and stripping entries off the front every time something failed and I had to restart, which is a little too manual for my taste :). (The list had to be sorted, otherwise port A might depend on port B that came later in the list, and when portmaster got to B in the list it would reinstall it again unnecessarily.) It also occurs to me that this could be completely automated if ports had a LAST_COMPATIBLE_VER field or some such, which tells you whether or not an upgrade-in-place is safe. portmaster could even ask 'you've just upgraded from foo-1.2 to foo-2.1 which is not compatible: do you want to rebuild which depended on the old version?'. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Cezary Morga wrote: > Alson van der Meulen pisze: >> * Doug Barton [2009-07-29 22:10]: >>> I'm planning to remove the -u option altogether. It actually does very >>> little now, and certainly does not do what most users expect it should >>> do. > > If I may chip in here on a similar note. > I'm currently looking for a port management tool that might replace good > ol' portinstall/portupgrade tools in my toolbox. Portmaster looks > promising but I noticed that it doesn't seem to take BATCH=yes in my > /etc/make.conf into consideration. So, is it me or there's something > more I have to do? Portmaster's operation and make.conf are completely separate. What portmaster does is essentially provide a wrapper for the functions of the ports infrastructure. Whenever portmaster runs 'make ' in a port your make.conf knobs will be honored. I expect that what you are seeing is a difference in how portmaster works vs. how other tools work. I would suggest that you read the man page for portmaster thoroughly, then if you have questions start a new thread on the freebsd-po...@freebsd.org list. Good luck, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Miroslav Lachman pisze: If I may chip in here on a similar note. I'm currently looking for a port management tool that might replace good ol' portinstall/portupgrade tools in my toolbox. Portmaster looks promising but I noticed that it doesn't seem to take BATCH=yes in my /etc/make.conf into consideration. So, is it me or there's something more I have to do? I think BATCH=yes is unrelated to portmaster. This variable is (should be) read by port build process it-self as if you build it by command cd /usr/ports/category/port & make install clean Well, when I install port directly (using `make install` in port's directory) BATCH flag is honored. When I install a port using portmaster it ain't. So, I'm wondering whether it's only me or not. -- Cezary Morga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Cezary Morga wrote: Alson van der Meulen pisze: * Doug Barton [2009-07-29 22:10]: I'm planning to remove the -u option altogether. It actually does very little now, and certainly does not do what most users expect it should do. If I may chip in here on a similar note. I'm currently looking for a port management tool that might replace good ol' portinstall/portupgrade tools in my toolbox. Portmaster looks promising but I noticed that it doesn't seem to take BATCH=yes in my /etc/make.conf into consideration. So, is it me or there's something more I have to do? I think BATCH=yes is unrelated to portmaster. This variable is (should be) read by port build process it-self as if you build it by command cd /usr/ports/category/port & make install clean Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Alson van der Meulen pisze: * Doug Barton [2009-07-29 22:10]: I'm planning to remove the -u option altogether. It actually does very little now, and certainly does not do what most users expect it should do. If I may chip in here on a similar note. I'm currently looking for a port management tool that might replace good ol' portinstall/portupgrade tools in my toolbox. Portmaster looks promising but I noticed that it doesn't seem to take BATCH=yes in my /etc/make.conf into consideration. So, is it me or there's something more I have to do? -- Cezary Morga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
* Doug Barton [2009-07-29 22:10]: > I'm planning to remove the -u option altogether. It actually does very > little now, and certainly does not do what most users expect it should > do. Fine by me. I've never actually used -u, with -d (or the equivalent portmaster.rc setting) it's usually fine for unattended runs. The only annoyance is the question about building interactive ports that don't actually require any interaction (bacula comes to mind), since this is the only question in the config phase that's not cached, but this is probably the port maintainers fault for marking it interactive (it does remind me of "no keyboard present, press F1 to continue"). Alson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
alson...@alm.flutnet.org wrote: > * Doug Barton [2009-07-29 20:48]: >> How about this? When the user has -[rf] but not -R, and there are flag >> files present, ask if they should be cleared before beginning to do >> anything. Otherwise (no -[rf]) ignore them. Sound good? > > Sounds like a good solution for both problems (stale flag files and > unexpected removal). Thanks. > It should default to removing the files with -u. I'm planning to remove the -u option altogether. It actually does very little now, and certainly does not do what most users expect it should do. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
* Doug Barton [2009-07-29 20:48]: > How about this? When the user has -[rf] but not -R, and there are flag > files present, ask if they should be cleared before beginning to do > anything. Otherwise (no -[rf]) ignore them. Sound good? Sounds like a good solution for both problems (stale flag files and unexpected removal). It should default to removing the files with -u. I think that -R is a very useful feature of portmaster, so I'm happy to see it getting improved. Thanks! Alson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Mel Flynn wrote: > On Wednesday 29 July 2009 10:48:33 Doug Barton wrote: >> Alson van der Meulen wrote: >>> * Doug Barton [2009-07-29 18:13]: Mel Flynn wrote: > Gotcha. Is there a reason the flags are removed if the options are not > "-r or -f"? Yes, so we don't have stale flags sitting around forever to confuse future runs. >>> I have been bitten by this in the past. A run of portmaster -r >>> some-lib-that-half-of-my-ports-depend-on aborted because of a shared >>> library error in a dependency which was not recompiled before the >>> dependent port. I recompiled the dependency with a manual portmaster >>> $portname, after this portmaster -r had to start all over. I didn't >>> expect portmaster to clear the PM_DONE flags during non-resumable >>> operations like rebuilding a single port (and the manpage contains very >>> little information about -R). My workaround is to use portupgrade for >>> these manual fixes. >> Yes, I've been considering that exact scenario since atm I'm >> rebuilding all my ports with -afR. >> >> How about this? When the user has -[rf] but not -R, and there are flag >> files present, ask if they should be cleared before beginning to do >> anything. Otherwise (no -[rf]) ignore them. Sound good? > > That's definitely "what you would expect it to do". Ok, good. I've refined that slightly so that if the user chooses not to delete them they are offered the option of enabling the -R option. Thanks for the feedback. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
On Wednesday 29 July 2009 10:48:33 Doug Barton wrote: > Alson van der Meulen wrote: > > * Doug Barton [2009-07-29 18:13]: > >> Mel Flynn wrote: > >>> Gotcha. Is there a reason the flags are removed if the options are not > >>> "-r or -f"? > >> > >> Yes, so we don't have stale flags sitting around forever to confuse > >> future runs. > > > > I have been bitten by this in the past. A run of portmaster -r > > some-lib-that-half-of-my-ports-depend-on aborted because of a shared > > library error in a dependency which was not recompiled before the > > dependent port. I recompiled the dependency with a manual portmaster > > $portname, after this portmaster -r had to start all over. I didn't > > expect portmaster to clear the PM_DONE flags during non-resumable > > operations like rebuilding a single port (and the manpage contains very > > little information about -R). My workaround is to use portupgrade for > > these manual fixes. > > Yes, I've been considering that exact scenario since atm I'm > rebuilding all my ports with -afR. > > How about this? When the user has -[rf] but not -R, and there are flag > files present, ask if they should be cleared before beginning to do > anything. Otherwise (no -[rf]) ignore them. Sound good? That's definitely "what you would expect it to do". -- Mel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Alson van der Meulen wrote: > * Doug Barton [2009-07-29 18:13]: >> Mel Flynn wrote: >>> Gotcha. Is there a reason the flags are removed if the options are not "-r >>> or >>> -f"? >> Yes, so we don't have stale flags sitting around forever to confuse >> future runs. > > I have been bitten by this in the past. A run of portmaster -r > some-lib-that-half-of-my-ports-depend-on aborted because of a shared > library error in a dependency which was not recompiled before the > dependent port. I recompiled the dependency with a manual portmaster > $portname, after this portmaster -r had to start all over. I didn't > expect portmaster to clear the PM_DONE flags during non-resumable > operations like rebuilding a single port (and the manpage contains very > little information about -R). My workaround is to use portupgrade for > these manual fixes. Yes, I've been considering that exact scenario since atm I'm rebuilding all my ports with -afR. How about this? When the user has -[rf] but not -R, and there are flag files present, ask if they should be cleared before beginning to do anything. Otherwise (no -[rf]) ignore them. Sound good? Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
