Subject: Re: bulk-build list
To: Dr. Rene Hexel <email@example.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 05/25/2001 22:51:20
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 --