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 -s text (Was: Re: HEADS-UP: Shared Library Versions bumped)
Doug Barton pisze: I can't speak for portupgrade but the vast majority of time with portmaster is actually spent building the port. The updating of /var/db/pkg is trivial in comparison. What portmaster does that bsd.port.mk by itself does not is allow you to update dependencies in place instead of having to uninstall the things that depend on them first, then reinstall them after the update. Actually, 'make deinstall' deinstalls given port without removing ports that depends on it. -- 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 do...@freebsd.org [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...)
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 -s text (Was: Re: HEADS-UP: Shared Library Versions bumped)
Cezary Morga wrote: Doug Barton pisze: I can't speak for portupgrade but the vast majority of time with portmaster is actually spent building the port. The updating of /var/db/pkg is trivial in comparison. What portmaster does that bsd.port.mk by itself does not is allow you to update dependencies in place instead of having to uninstall the things that depend on them first, then reinstall them after the update. Actually, 'make deinstall' deinstalls given port without removing ports that depends on it. So does 'pkg_delete -f', that's not the issue. If you delete the port by either of those methods then reinstall it the regular way you will lose dependency tracking information. (I should have been more clear in the post you quoted.) 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...)
Cezary Morga wrote: Alson van der Meulen pisze: * Doug Barton do...@freebsd.org [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 something' 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...)
Quoth Doug Barton do...@freebsd.org: 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 list of pkgs 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...)
Alson van der Meulen pisze: * Doug Barton do...@freebsd.org [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: HEADS-UP: Shared Library Versions bumped...
Mel Flynn wrote: I wrapped portmaster, since -af has the same problem when something screws the build (mostly plist problems and $me wanting backup packages, but also classics like using sudo as PM_SU_CMD and trying to reinstall it). I hate to tell you but portmaster already has the ability to restart after an interrupted -af. See the man page regarding the -R option. So you can do this the first time: portmaster -Daf Then do this the second (or more) time: portmaster -DGRaf The one caveat is that you don't want to run any other portmaster commands in between since it will remove all the flags when it exits successfully. 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: HEADS-UP: Shared Library Versions bumped...
On Tuesday 28 July 2009 23:10:50 Doug Barton wrote: Mel Flynn wrote: I wrapped portmaster, since -af has the same problem when something screws the build (mostly plist problems and $me wanting backup packages, but also classics like using sudo as PM_SU_CMD and trying to reinstall it). I hate to tell you but portmaster already has the ability to restart after an interrupted -af. See the man page regarding the -R option. Maybe that can be cleared up: -R restart an update, skipping ports already up to date. Used with -r ^^ or -f options. Yes, I should've gathered what it meant when reading or -f options, but I never read that far. Perhaps that could read ... already done in the previous run. So you can do this the first time: portmaster -Daf Then do this the second (or more) time: portmaster -DGRaf And with the above in EXAMPLES. The one caveat is that you don't want to run any other portmaster commands in between since it will remove all the flags when it exits successfully. Gotcha. Is there a reason the flags are removed if the options are not -r or -f? -- 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
Re: HEADS-UP: Shared Library Versions bumped...
Mel Flynn wrote: On Tuesday 28 July 2009 23:10:50 Doug Barton wrote: Mel Flynn wrote: I wrapped portmaster, since -af has the same problem when something screws the build (mostly plist problems and $me wanting backup packages, but also classics like using sudo as PM_SU_CMD and trying to reinstall it). I hate to tell you but portmaster already has the ability to restart after an interrupted -af. See the man page regarding the -R option. Maybe that can be cleared up: -R restart an update, skipping ports already up to date. Used with -r ^^ or -f options. Yes, I should've gathered what it meant when reading or -f options, but I never read that far. Perhaps that could read ... already done in the previous run. How about this: used with the -r or -f options to skip ports updated on a previous run. So you can do this the first time: portmaster -Daf Then do this the second (or more) time: portmaster -DGRaf And with the above in EXAMPLES. Good suggestion, thanks. The one caveat is that you don't want to run any other portmaster commands in between since it will remove all the flags when it exits successfully. 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. 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: HEADS-UP: Shared Library Versions bumped...
* Doug Barton do...@freebsd.org [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. The case where not removing the flags without -[rf] would hurt is running portmaster -r something, portmaster failing, resolving this without portmaster -[rf], updating your ports, and run portmaster -R. It seems fair to consider this behavior undefined. Plus the ports can be modified in many ways without portmaster, so it would make more sense to try to detect stale PM_DONE flags than removing them at arbitrary times (eg. compare the timestamp of the flag to that of the port). 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
portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
Alson van der Meulen wrote: * Doug Barton do...@freebsd.org [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
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 do...@freebsd.org [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
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 do...@freebsd.org [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...)
* Doug Barton do...@freebsd.org [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...)
alson...@alm.flutnet.org wrote: * Doug Barton do...@freebsd.org [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 do...@freebsd.org [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 -s text (Was: Re: HEADS-UP: Shared Library Versions bumped)
This sort of mechanism has been suggested before, but the problem you described (ports installed on purpose becoming a dependency of something else) is not an easy one to solve. I don't earlly see why that is a problem tha needs solving. cerrtainl all I want is to be able to list ports installed by hand, regardless of whether the later became dependencies of other ports. Just a nice simple way to be able to say what did I install on this? before wiping all ports and upgrading would be nice. -pete. ___ 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 -s text (Was: Re: HEADS-UP: Shared Library Versions bumped)
Doug Barton wrote: On Thu, 23 Jul 2009, Ben Morrow wrote: The problem with that is if you install pkg A deliberately, but it then later becomes a dependancy of pkg B. If you remove pkg B (because it's no longer needed) there is then no evidence that pkg A was installed on purpose, rather than incidentally. portmaster -s will offer to remove it, and if you refuse it will offer to remove the empty +REQUIRED_BY, effectively promoting it to a 'manually installed' pkg again, though it's perhaps not entirely clear from the question that that is what the effect will be. Thanks for pointing this out. Can you suggest an alternative message? Other than the mundane reason the current message says what it does because I sometimes prefer to leave the empty file there so that when I go back through at a later date I can re-evaluate the choice. Yes, I can see it needs to be an option. Presumably 'don't ask me again' is too Microsoft :)? Maybe something like 'Mark this package as explicitly required?'? That's pretty much the user-visible effect. I know the first time I saw that message, when I didn't really understand what it meant, my reaction was 'Delete something? No!' which wasn't the right answer. This would be easy to solve in general by maintaining a 'world' package, or some such, that had dependencies on everything installed explicitly; but that would require modifying all the pkg and port installation tools (probably including bsd.port.mk itself) to support that convention. This sort of mechanism has been suggested before, but the problem you described (ports installed on purpose becoming a dependency of something else) is not an easy one to solve. No. I have occasionally wondered if a sensible solution would be to drop portmaster/portupgrade altogether and just maintain a local sysutils/world port with a list of what I want installed, and 'make deinstall reinstall' whenever it changes (with something like pkg_cutleaves to clear out the trash). I suspect I would lose something I'm currently relying on (certainly, portmaster's -o and -r options wouldn't be trivial to emulate) but it does seem to me that both portmaster and portupgrade spend an awful lot of time doing things like tracking dependancies that bsd.port.mk already does for you. 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 -s text (Was: Re: HEADS-UP: Shared Library Versions bumped)
On Tue, 28 Jul 2009, Ben Morrow wrote: Yes, I can see it needs to be an option. Presumably 'don't ask me again' is too Microsoft :)? Maybe something like 'Mark this package as explicitly required?'? That's pretty much the user-visible effect. Thanks for the suggestions. I know the first time I saw that message, when I didn't really understand what it meant, my reaction was 'Delete something? No!' which wasn't the right answer. Yeah, looking back on this from the user perspective it wasn't the best choice of messages. No. I have occasionally wondered if a sensible solution would be to drop portmaster/portupgrade altogether and just maintain a local sysutils/world port with a list of what I want installed, and 'make deinstall reinstall' whenever it changes (with something like pkg_cutleaves to clear out the trash). I suspect I would lose something I'm currently relying on (certainly, portmaster's -o and -r options wouldn't be trivial to emulate) but it does seem to me that both portmaster and portupgrade spend an awful lot of time doing things like tracking dependancies that bsd.port.mk already does for you. I can't speak for portupgrade but the vast majority of time with portmaster is actually spent building the port. The updating of /var/db/pkg is trivial in comparison. What portmaster does that bsd.port.mk by itself does not is allow you to update dependencies in place instead of having to uninstall the things that depend on them first, then reinstall them after the update. 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
portmaster -s text (Was: Re: HEADS-UP: Shared Library Versions bumped)
On Thu, 23 Jul 2009, Ben Morrow wrote: The problem with that is if you install pkg A deliberately, but it then later becomes a dependancy of pkg B. If you remove pkg B (because it's no longer needed) there is then no evidence that pkg A was installed on purpose, rather than incidentally. portmaster -s will offer to remove it, and if you refuse it will offer to remove the empty +REQUIRED_BY, effectively promoting it to a 'manually installed' pkg again, though it's perhaps not entirely clear from the question that that is what the effect will be. Thanks for pointing this out. Can you suggest an alternative message? Other than the mundane reason the current message says what it does because I sometimes prefer to leave the empty file there so that when I go back through at a later date I can re-evaluate the choice. This would be easy to solve in general by maintaining a 'world' package, or some such, that had dependencies on everything installed explicitly; but that would require modifying all the pkg and port installation tools (probably including bsd.port.mk itself) to support that convention. This sort of mechanism has been suggested before, but the problem you described (ports installed on purpose becoming a dependency of something else) is not an easy one to solve. 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: HEADS-UP: Shared Library Versions bumped...
On Wed, 22 Jul 2009, John Baldwin wrote: How many of those 800 ports are actually necessary and used? It would be better to get generate a complete list of your installed ports, use pkg_deinstall or pkg_delete to remove all ports, and then selectively re-install ports that are actually used. Xorg takes up ~200 ports alone (not including dependencies like perl, etc.) since the Xorg decided release engineering was too hard. Throw in things like KDE, OOo, Firefox, etc. for a desktop and you can get a fairly high package count. :-/ Ooh I only have 1315 on mine, but a 1.4GHz Pentium-M is pretty slow these days :( Perhaps there needs to be a psuedo port for 'base' (or a few) so that you can easily determine if you have already upgraded something against the new base you installed. Certainly I find it difficult to leave my laptop on for long enough to recompile everything when I upgrade -current (since I actually use it for work), and portupgrade -fa has no way to tell if it's already done something. If there were pseudo base ports you could tell it to force upgrade everything that depends on the old base port and it would DTRT. I, of course, have no patches for such a thing :) I've deleted /usr/local /var/db/pkg in the past, it can be very therapeutic :) However it is not so good when your mp3 collection is mounted on /usr/local/mp3 and you forgot to unmount it first.. :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: HEADS-UP: Shared Library Versions bumped...
On Thursday 23 July 2009 22:55:07 Daniel O'Connor wrote:
On Wed, 22 Jul 2009, John Baldwin wrote:
How many of those 800 ports are actually necessary and used?
It would be better to get generate a complete list of your
installed ports, use pkg_deinstall or pkg_delete to remove
all ports, and then selectively re-install ports that are
actually used.
Xorg takes up ~200 ports alone (not including dependencies like perl,
etc.) since the Xorg decided release engineering was too hard. Throw
in things like KDE, OOo, Firefox, etc. for a desktop and you can get
a fairly high package count. :-/
Ooh I only have 1315 on mine, but a 1.4GHz Pentium-M is pretty slow
these days :(
Perhaps there needs to be a psuedo port for 'base' (or a few) so that
you can easily determine if you have already upgraded something against
the new base you installed.
Certainly I find it difficult to leave my laptop on for long enough to
recompile everything when I upgrade -current (since I actually use it
for work), and portupgrade -fa has no way to tell if it's already done
something. If there were pseudo base ports you could tell it to force
upgrade everything that depends on the old base port and it would DTRT.
I wrapped portmaster, since -af has the same problem when something screws the
build (mostly plist problems and $me wanting backup packages, but also
classics like using sudo as PM_SU_CMD and trying to reinstall it).
Basically, I made a list of all the installed ports and sorted dep order, then
called portmaster -u for every port and if successful put an empty file
+PM_DONE in /var/db/pkg/pkgname/. On a restart the ports containing a
+PM_DONE file are skipped.
If the entire process finishes successfully, all +PM_DONE files are removed. I
briefly looked into building it into portmaster, but that looked to take
longer then I had time for. The main loop is at the bottom, perhaps Doug likes
the idea and has the time to integrate it.
I, of course, have no patches for such a thing :)
I've deleted /usr/local /var/db/pkg in the past, it can be very
therapeutic :) However it is not so good when your mp3 collection is
mounted on /usr/local/mp3 and you forgot to unmount it first.. :(
Or your websites in /usr/local/www, your database in /usr/local/pgsql or your
squid conf and cache in /usr/local/squid. Especially when pkg_delete -af does
the right thing and leaves all this in tact, I don't see the value of rm -rf
/usr/local, other then a few minutes on a process that's likely going to be
several hours or days.
--
Mel
mark_done()
{
local _name
_name=$1
if test -d ${PKG_DBDIR}/${_name}; then
${SUDO} ${TOUCH} ${PKG_DBDIR}/${_name}/+PM_DONE
else
return 1;
fi
return 0;
}
for origin in ${LIST}; do
pkgname=$(make -C ${PORTSDIR}/${origin} -V PKGNAME)
if test -f ${PKG_DBDIR}/${pkgname}/+PM_DONE; then
echo Already done: ${pkgname} (${LOOP}/${TOTAL})
else
echo === Building ${pkgname}
portmaster -u ${PORTSDIR}/${origin}
if test $? -eq 0; then
mark_done ${pkgname} || safe_abort
else
FAILED=$((${FAILED} + 1))
echo Failed, continue? [n]
read CONT
case ${CONT} in
[yY]|[yY][eE]|[yY][eE][sS])
echo === Marking state as done
mark_done ${pkgname} || safe_abort
;;
*) break;;
esac
fi
fi
done
if test ${FAILED} -eq 0; then
echo === Removing state files
for FILE in ${PKG_DBDIR}/*/+PM_DONE; do
${SUDO} /bin/rm ${FILE}
done
echo === Removing origin list
/bin/rm ${LISTFILE}
fi
___
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: HEADS-UP: Shared Library Versions bumped...
On Tuesday 21 July 2009 5:52:01 pm Steve Kargl wrote: On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you imagine how long this box will be occupied by 'portupgrade -af'? I guess 'cherry-picking' is the only solution. How many of those 800 ports are actually necessary and used? It would be better to get generate a complete list of your installed ports, use pkg_deinstall or pkg_delete to remove all ports, and then selectively re-install ports that are actually used. Xorg takes up ~200 ports alone (not including dependencies like perl, etc.) since the Xorg decided release engineering was too hard. Throw in things like KDE, OOo, Firefox, etc. for a desktop and you can get a fairly high package count. :-/ -- John Baldwin ___ 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: HEADS-UP: Shared Library Versions bumped...
В вт, 21/07/2009 в 14:52 -0700, Steve Kargl пишет: On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you imagine how long this box will be occupied by 'portupgrade -af'? I guess 'cherry-picking' is the only solution. How many of those 800 ports are actually necessary and used? It would be better to get generate a complete list of your installed ports, use pkg_deinstall or pkg_delete to remove all ports, and then selectively re-install ports that are actually used. I've found that much faster and cleaner way is to just remove whole /usr/local (preserving /usr/local/etc), and /var/db/pkg and then just install required ports, such process goes much faster. Also it removes all unused ports. As for ports number, it is really crazy, I have 1435 ports for notebook used as usual desktop and as multi-purpose development machine. PS. I am on i386, so can't say anything about amd64 specific performance problems. -- Vladimir B. Grebenschikov v...@fbsd.ru ___ 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: HEADS-UP: Shared Library Versions bumped...
On Wed, Jul 22, 2009, Vladimir Grebenschikov wrote: В вт, 21/07/2009 в 14:52 -0700, Steve Kargl пишет: On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you imagine how long this box will be occupied by 'portupgrade -af'? I guess 'cherry-picking' is the only solution. How many of those 800 ports are actually necessary and used? It would be better to get generate a complete list of your installed ports, use pkg_deinstall or pkg_delete to remove all ports, and then selectively re-install ports that are actually used. I've found that much faster and cleaner way is to just remove whole /usr/local (preserving /usr/local/etc), and /var/db/pkg and then just install required ports, such process goes much faster. Also it removes all unused ports. I do the same thing. I wish the ports system kept track of which ports were installed explicitly by me, and which were only dependencies. Then it would be possible to garbage collect ports that are no longer needed. ___ 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: HEADS-UP: Shared Library Versions bumped...
On Wed, 2009-07-22 at 15:30 -0400, David Schultz wrote: On Wed, Jul 22, 2009, Vladimir Grebenschikov wrote: В вт, 21/07/2009 в 14:52 -0700, Steve Kargl пишет: On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you imagine how long this box will be occupied by 'portupgrade -af'? I guess 'cherry-picking' is the only solution. How many of those 800 ports are actually necessary and used? It would be better to get generate a complete list of your installed ports, use pkg_deinstall or pkg_delete to remove all ports, and then selectively re-install ports that are actually used. I've found that much faster and cleaner way is to just remove whole /usr/local (preserving /usr/local/etc), and /var/db/pkg and then just install required ports, such process goes much faster. Also it removes all unused ports. I do the same thing. I wish the ports system kept track of which ports were installed explicitly by me, and which were only dependencies. ports-mgmt/pkg_cutleaves does not quite do that, but IMHO is pretty close. I does not detect build-time dependencies, though. Then it would be possible to garbage collect ports that are no longer needed. ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Alexandre Kovalenko (Олександр Коваленко) ___ 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: HEADS-UP: Shared Library Versions bumped...
On Wed, Jul 22, 2009 at 03:30:33PM -0400, David Schultz wrote: I do the same thing. I wish the ports system kept track of which ports were installed explicitly by me, and which were only dependencies. Then it would be possible to garbage collect ports that are no longer needed. Portmaster -s will cull ports that are no longer depended on. Seems to work fairly well. You can (probably) find the list of ports that you installed deliberately by trawling through /var/db/pkg for those that don't have a +REQUIRED_BY file. (The portmaster -s trick works by finding ports that have a +REQUIRED_BY file that is empty, I believe.) Cheers, -- Andrew ___ 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: HEADS-UP: Shared Library Versions bumped...
Quoth Andrew Reilly andrew-free...@areilly.bpc-users.org: On Wed, Jul 22, 2009 at 03:30:33PM -0400, David Schultz wrote: I do the same thing. I wish the ports system kept track of which ports were installed explicitly by me, and which were only dependencies. Then it would be possible to garbage collect ports that are no longer needed. Portmaster -s will cull ports that are no longer depended on. Seems to work fairly well. You can (probably) find the list of ports that you installed deliberately by trawling through /var/db/pkg for those that don't have a +REQUIRED_BY file. (The portmaster -s trick works by finding ports that have a +REQUIRED_BY file that is empty, I believe.) The problem with that is if you install pkg A deliberately, but it then later becomes a dependancy of pkg B. If you remove pkg B (because it's no longer needed) there is then no evidence that pkg A was installed on purpose, rather than incidentally. portmaster -s will offer to remove it, and if you refuse it will offer to remove the empty +REQUIRED_BY, effectively promoting it to a 'manually installed' pkg again, though it's perhaps not entirely clear from the question that that is what the effect will be. This would be easy to solve in general by maintaining a 'world' package, or some such, that had dependencies on everything installed explicitly; but that would require modifying all the pkg and port installation tools (probably including bsd.port.mk itself) to support that convention. 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: HEADS-UP: Shared Library Versions bumped...
Olivier SMEDTS wrote: 2009/7/19 Thomas Backman seren...@exscape.org: On Jul 19, 2009, at 20:16, Ken Smith wrote: The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. �When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. �However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. So, to be clear: a fresh ports tree and portupgrade -af after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) But there won't be any problem until you do a make delete-old-libs in /usr/src/, right ? Olivier Regards, Thomas ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Real fun this moment. It took appoximately 13 hours on a two socket, 8 core Dell PowerEdge 1950 III at 2,5 GHz with 16 GB RAM for 453 ports to be recompiled. I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you imagine how long this box will be occupied by 'portupgrade -af'? I guess 'cherry-picking' is the only solution. FreeBSD 8.0 on AMD64 does have serious performance issues these days, try to compile a compiler (gcc44, for instance) and watch how bumpy your X11 or how network traffic on a 'headless' server becomes. Kernel compilation time has been increased by approx 10 minutes on the 8 core box with 16 GB RAM since ~ 4 months now. I know, this is a kind of off topic for the questiojns discussed at the moment, but I guess those problems and fun are guaranteed for those having lots of ports, FreeBSD 8 running on AMD64 ;-)) Regards, Oliver ___ 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: HEADS-UP: Shared Library Versions bumped...
On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you imagine how long this box will be occupied by 'portupgrade -af'? I guess 'cherry-picking' is the only solution. How many of those 800 ports are actually necessary and used? It would be better to get generate a complete list of your installed ports, use pkg_deinstall or pkg_delete to remove all ports, and then selectively re-install ports that are actually used. FreeBSD 8.0 on AMD64 does have serious performance issues these days, try to compile a compiler (gcc44, for instance) and watch how bumpy your X11 or how network traffic on a 'headless' server becomes. Kernel compilation time has been increased by approx 10 minutes on the 8 core box with 16 GB RAM since ~ 4 months now. I know, this is a kind of off topic for the questiojns discussed at the moment, but I guess those problems and fun are guaranteed for those having lots of ports, FreeBSD 8 running on AMD64 ;-)) I compile gcc trunk on my 2 cpu amd64 based system almost everyday. I don't see the performance issue you seem to have. Do you use ULE? If yes, then switch to 4BSD. -- Steve ___ 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: HEADS-UP: Shared Library Versions bumped...
On Mon, Jul 20, 2009 at 04:29:39PM +0200, Olivier SMEDTS wrote: 2009/7/19 Thomas Backman seren...@exscape.org: So, to be clear: a fresh ports tree and portupgrade -af after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) But there won't be any problem until you do a make delete-old-libs in /usr/src/, right ? Cherry-picking of the ports to upgrade is also problematic, as well as a compilation of third party software. pgpDkOGOxnFLF.pgp Description: PGP signature
Re: HEADS-UP: Shared Library Versions bumped...
2009/7/19 Thomas Backman seren...@exscape.org: On Jul 19, 2009, at 20:16, Ken Smith wrote: The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. So, to be clear: a fresh ports tree and portupgrade -af after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) But there won't be any problem until you do a make delete-old-libs in /usr/src/, right ? Olivier Regards, Thomas ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: HEADS-UP: Shared Library Versions bumped...
Date: Mon, 20 Jul 2009 16:29:39 +0200 From: Olivier SMEDTS oliv...@gid0.org Sender: owner-freebsd-curr...@freebsd.org 2009/7/19 Thomas Backman seren...@exscape.org: On Jul 19, 2009, at 20:16, Ken Smith wrote: The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. So, to be clear: a fresh ports tree and portupgrade -af after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) But there won't be any problem until you do a make delete-old-libs in /usr/src/, right ? Wrong. As soon as you start updating ports you will start getting apps which link to both old and new versions and that does not work. If you don't update any ports which provide shared libs, you are OK. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: HEADS-UP: Shared Library Versions bumped...
Quoting Ken Smith kensm...@cse.buffalo.edu: First I want to apologize. This should have happened a bit sooner in our release cycle than now. To be honest I had slipped into We have symbol versioning for our libraries now mode. But only a few of the libraries currently have that turned on and I sorta forgot we still need to deal with all the shared libraries that do not have symbol versioning enabled yet. Sorry for the hassle this will cause. ...snip... Wouldn't this be a great opportunity to fix kern/133926 by bumping up the max username length? -- Chris Dillon - NetEng/SysAdm Reeds Spring R-IV School District Technology Department 175 Elementary Rd. Reeds Spring, MO 65737 Voice: 417-272-8266 Fax: 417-272-0015 ___ 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
HEADS-UP: Shared Library Versions bumped...
First I want to apologize. This should have happened a bit sooner in our release cycle than now. To be honest I had slipped into We have symbol versioning for our libraries now mode. But only a few of the libraries currently have that turned on and I sorta forgot we still need to deal with all the shared libraries that do not have symbol versioning enabled yet. Sorry for the hassle this will cause. Today with svn commit 195767 I bumped the version number of all non-symbol-version-ed shared libraries in preparation for 8.0-REL. We do this just in case API/ABI changes occured in head between 7.0 and now, it lets us provide the older library versions as compatibility library ports in the ports tree. The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. The ports folks will be starting up a fresh package build now but it takes some time for full package runs like this to complete, get uploaded, and then propagate out to the mirrors. If you tend to use pre-built packages instead of building them as ports yourself you might want to just hold off on updating anything until they let us know a fresh set of packages is available. And BETA3 will definitely be scheduled for after the fresh set of packages becomes available. And again - sorry for the hassle. -- Ken Smith - From there to here, from here to | kensm...@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: HEADS-UP: Shared Library Versions bumped...
On Sun, 2009-07-19 at 20:26 +0200, Thomas Backman wrote: On Jul 19, 2009, at 20:16, Ken Smith wrote: The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. So, to be clear: a fresh ports tree and portupgrade -af after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) Correct for those of you who let portupgrade do all the building for you (which the example command you give does). The reason I'm being careful is portupgrade can also be told to fetch pre-built packages. At the moment that will not work, if you use that approach please hold off until the ports folks let us know the packages have been rebuilt. -- Ken Smith - From there to here, from here to | kensm...@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: HEADS-UP: Shared Library Versions bumped...
On Jul 19, 2009, at 20:16, Ken Smith wrote: The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. So, to be clear: a fresh ports tree and portupgrade -af after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) Regards, Thomas ___ 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: HEADS-UP: Shared Library Versions bumped...
Ken Smith kensm...@cse.buffalo.edu writes: First I want to apologize. This should have happened a bit sooner in our release cycle than now. To be honest I had slipped into We have symbol versioning for our libraries now mode. But only a few of the libraries currently have that turned on and I sorta forgot we still need to deal with all the shared libraries that do not have symbol versioning enabled yet. Sorry for the hassle this will cause. Today with svn commit 195767 I bumped the version number of all non-symbol-version-ed shared libraries in preparation for 8.0-REL. We do this just in case API/ABI changes occured in head between 7.0 and now, it lets us provide the older library versions as compatibility library ports in the ports tree. The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. The ports folks will be starting up a fresh package build now but it takes some time for full package runs like this to complete, get uploaded, and then propagate out to the mirrors. If you tend to use pre-built packages instead of building them as ports yourself you might want to just hold off on updating anything until they let us know a fresh set of packages is available. And BETA3 will definitely be scheduled for after the fresh set of packages becomes available. And again - sorry for the hassle. In my case, there is no upgrade with servers -- i have two servers (4.11-STABLE, 6.3-RELEASE). So plz don't worry. Only what i do upgrade is client which is my main desktop -- currently it runs as 7.2-RELEASE. Though! Don't worry because always i do upgrade as follow: = csup = make world = reboot = (after coffee time) = pkg_delete -af = pkg_add -r -v gnome (with several package) That's very fine and fast for me, anyway... -- Byung-Hee HWANG, KNU ∑ WWW: http://izb.knu.ac.kr/~bh/ Come on, stick it in. Stick it in, Johnny, that's what you really want. -- Margot Ashton, Chapter 1, page 12 ___ 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
