Date: Tue, 24 Jan 2012 12:50:00 +0200 From: Volodymyr Kostyrko <c.kworr@gmail.com> To: Victor Sudakov <vas@mpeks.tomsk.su> Cc: freebsd-questions@freebsd.org Subject: Re: portmaster best practices Message-ID: <4F1E8CD8.6060105@gmail.com> In-Reply-To: <20120124084110.GA99094@admin.sibptus.tomsk.ru> References: <20120123103232.GA79175@admin.sibptus.tomsk.ru> <4F1D7844.8060807@gmail.com> <20120124084110.GA99094@admin.sibptus.tomsk.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Victor Sudakov wrote: >>> If portaudit shows that some installed packages have vulnerabilities, >>> what do you usually do? >> >> Greatly depend on where am I. All my systems are staying up-to-date >> whereas when I'm visiting someones system I prefer to update only >> required pieces of software. Anyway if you tell portmaster to update >> port x it would try to update all ports it depends on. > > Does it often screw things up when updating dependencies (both > ascending and descending ones)? Do you recommend to always update the > ascending dependencies (portmaster -r) also? I never faced any problems updating ports with portmaster. Mostly because portmaster always backups old libraries to compat folder for me as stated in my configuration file: /usr/local/etc/portmaster.rc: NO_BACKUP=Bopt PM_VERBOSE=vopt SAVE_SHARED=wopt DONT_SCRUB_DISTFILES=Dopt NO_BACKUP means don't create a temporary package when deleting something. This is unsuitable for me as /usr/ports in my network is distributed via NFS ro. PM_VERBOSE increases detail level. SAVE_SHARED is a must, it tells portmaster to propagate deleted shared libraries to compat directory. This way updating any port to newer lib version will have no impact on ports requiring previous versions. DONT_SCRUB_DISTFILES also is redundant for me as /usr/ports is read only and I don't want to drop sources of python 2.5 when building python 2.7 as python2.5 is still needed for AppEngine for example. Personally I never use -r as anything that can be fixed with that one can be fixed with pkg_libchk and careful planning. >> The better way of debugging such problems for me is pkg_libchk from >> sysutils/bsdadminscripts. > > I use sysutils/libchk when I have to, but it is a tedious manual job I > would like to avoid. They are almost the same except pkg_libchk doesn't depend on ruby and works in parallel better (for me). -- Sphinx of black quartz judge my vow.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F1E8CD8.6060105>