Stable tag will be slipped Sunday and release engineering will begin Monday
okumoto at ucsd.edu
Tue Apr 5 16:10:59 PDT 2005
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
Message-ID: <42531b00$0$716$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
X-Trace: 1112742656 crater_reader.dragonflybsd.org 716 184.108.40.206
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.
Or at least, write a script to impliment Joerg's idea of a jailed
# 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
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.
Starts up a shell within the jail, so you can test
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.
More information about the Users