On Fri, 25 May 2001, Dr. Rene Hexel wrote:

> Frederick Bruckman wrote:
>
> > Granted, if we do the version numbers right, it forces people to
> > update lots of packages, but doing it as we have been doing it,
> > haphazardly, is worse, as it makes people have to update all of them.
>
>   There is one thing that would ease up things a lot: in-place package
> updates.  As Jason suggested earler, what we'd need to have is some sort
> of 'pkg_update' or 'pkg_add -u' that keeps older versions of shared
> libraries.  This way, a user could update a package like 'png' without
> deinstalling and reinstalling a bunch of dependent packages.
>
>   This doesn't alleviate the burden for us developers of uploading a
> consistent set of binaries onto the ftp server (well, we could upload
> some 'hybrid' packages like a png-1.0.11 that also contains
> library.so.<previousversion>, but I'd consider this a last resort).
> However, it would make it a lot easier for the average user to update
> packages in place without having to worry about shared library linking.

	I agree with Dan that we should upload a complete set of packages
	built against the release tag after a release. I think they should
	replace any packages built against the previous minor release
	(eg: 1.5 -> 1.5.1, or 1.4.2 -> 1.4.3)

	If one person is using the bulk build system for a given arch+osrev
	then even with the current system a png update that changed
	a shared library number, or even made it incompatible would still
	result in a consistent set of packages.

	On slower architectures the interval between updates will be long,
	but probably still shorter than the interval between releases :)

	I agree we need to fix the shared library issue, but it is
	orthogonal to generating a consistent set of binary packages for
	ftp.netbsd.org using bulk-building.

	Does anyone have a better option or variation towards that end?


-- 
		David/absolute		-- www.netbsd.org: No hype required --