On Fri, Jun 24, 2005 at 06:32:51AM -0700, Jeremy C. Reed wrote:
> On Wed, 22 Jun 2005, Sean Davis wrote:
> 
> > why is it necessary to nuke
> > every package before rebuilding? why not build, and IF IT BUILDS, then nuke
> > and reinstall? That seems to be the saner course of action to me. That way
> > I'm not left with half the packages I had before because I updated one
> > relatively insignifigant package that some weird dependency chain linked to
> > KDE, and then to everything else.
> 
> I don't see how this will consistently work. If you want to update a
> package and it requires new headers/libraries/features from a dependency
> package, then that dependency packages must be rebuilt.
> 
> And it doesn't make sense to reinstall the dependency package if not
> compatible with all the packages depending on it -- so they should all be
> removed.
> 
> Also, we (usually) don't want to reinstall a package when it is still
> installed, so we deinstall it first. And since other packages may depend
> on now missing functionality, we make sure they are deinstalled also.
> 
> I have no problem with the removal of packages first. Using pkgsrc on
> production system like this would not work for me. I do use packages made
> from pkgsrc on production systems.
> 
> As for me I rarely use make update and I don't use pkg_comp. I just use a
> different system to do my builds. Or I use a chroot environment which I
> manually build.

Needing another machine just for package builds is silly. No other *NIX OS
requires that. That's just as silly as requiring a full NetBSD release to
build one package (ala pkg_comp). If FreeBSD can do this in a sane manner,
with portupgrade (however it works)... so can pkgsrc. If NetBSD isn't going
to provide up to date binary packages for every branch (which would require
quite a lot of build hardware)... then NetBSD needs to provide a means for
updating a package without removing everything first, for people who want to
keep their system usable until the package is ready to install.

> 
> I also frequently use IGNORE_RECOMMENDED=yes on systems (that don't create
> binary packages) and it makes it easier.
> 
> I have also been using this mk/bsd.pkg.mk addition:
> 
>  		${ECHO_MSG} "${_PKGSRC_IN}> Required installed package
> $$pkg: $${found} found"; \
>  	else								\
>  		${ECHO_MSG} "${_PKGSRC_IN}> Required package $$pkg: NOT
> found"; \
> +		found=`${PKG_ADMIN} -d "${PKGREPOSITORY}" lsbest "$$pkg"`
> ; \
> +		if ${PKG_INFO} -qe ${dep:C/:.*$//:C/[=><-].*$//:Q} ; then
> \
> +			${ECHO_MSG} "${_PKGSRC_IN}> Older package that is
> not good enough was found already installed.";	\
> +		fi;							\
> +		if [ -n "$$found" -a -n "${MY_BIN_INSTALL}" ] ; then	\
> +			${ECHO_MSG} "${_PKGSRC_IN}> Installing existing
> $$found ... " ; \
> +			${SU_CMD} "${PKG_ADD} ${_BIN_INSTALL_FLAGS}
> $$found" ; \
> +		else							\
> +			if [ -n "$$found" ] ; then			\
> +				${ECHO_MSG} "${_PKGSRC_IN}> $$found
> exists, but not using." ; \
> +			fi;						\
>  		target=${DEPENDS_TARGET:Q};				\
>  		${ECHO_MSG} "${_PKGSRC_IN}> Verifying $$target for $$dir";
> \
>  		if [ ! -d $$dir ]; then					\
> @@ -3650,6 +3677,7 @@
>  			${SETENV} _PKGSRC_DEPS=",
> ${PKGNAME}${_PKGSRC_DEPS}" ${MAKE} ${MAKEFLAGS} $$target
> PKGNAME_REQD=\'$$pkg\' MAKEFLAGS="" || exit 1; \
>  			${ECHO_MSG} "${_PKGSRC_IN}> Returning to build of
> ${PKGNAME}"; \
>  		fi;							\
> +		fi;	\
>  	fi
>  .      endfor	# DEPENDS
> 
> 
> Sorry it is out of context, as I have other changes too.
> 
> But basically it is an improvement on the bin-install target, as it does
> not run as root the whole time and it only rebuilds packages if needed. It
> has problems, but has saved me a lot of time. (I make sure I always
> generate binary packages for reuse on this system.)
> 
> > I'm tired of it. So: what'll it be? money? hardware? or should I just act
> > like nothing is wrong with the update target, like the pkgsrc developers do?
> 
> I can't speak for that. But I am guessing that "make update" must work for
> some of the developers.

make update does work in that it functions as designed; however, if one
single package doesn't build, one is left missing every package that it
removed minus whatever it installed before that one single package, which
sucks. And some packages stay broken for days/weeks... (hi there,
audio/xmms-flac...)

-Sean