Stable tag will be slipped Sunday and release engineering will begin Monday

[Max Okumoto]

0050405140241.GF1443 at xxxxxxxxxxxxxxxxx> <42530abe$0$717$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200504052232.j35MWID4086845 at xxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <200504052232.j35MWID4086845 at xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 40
Message-ID: <42531b00$0$716$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 132.239.18.178
X-Trace: 1112742656 crater_reader.dragonflybsd.org 716 132.239.18.178
Xref: crater_reader.dragonflybsd.org dragonfly.users:2759

Matthew Dillon wrote:
>     I think this is starting to rehash old issues.  I've already said
>     that my requirements for a packaging system are at a minimum to allow
>     multiple versions of any given program or library to be installed
>     at the same time.  That hasn't changed.
> 
>     With all the effort people are putting into this, maybe we *should*
>     go off and create our own environment.
> 
> 					-Matt

Or at least, write a script to impliment Joerg's idea of a jailed
upgrade area.
   Rev 1:
	# upgrader_build -D date -p pkg_list
		Just copy everything into a jail, build the
		list of ports that you want to upgrade.  Have
		the script generate a diff of files in /etc and
		/usr/local/etc so you can tell what config files
		changed.

		The date would be a CVS date string so that
		cvsup would check out a specific version of
		the files, which makes the build repeatable.

		The pkg_list file should contain the ports that
		you want to build.

	# upgrader_shell
		Starts up a shell within the jail, so you can test
		your applications.

	# upgrader_install
		mv /usr/local and /usr/X11R6 into backup areas, and
		then copy the results into place.

Rev 2: Optimize copy by using links or mounts.
Rev 3: Use some sort of layered file system
Rev 5: etc.