Date: Tue, 13 Apr 2004 14:02:55 +0800 From: Erich Dollansky <oceanare@pacific.net.sg> To: Robin Schoonover <end@endif.cjb.net> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: Second "RFC" on pkg-data idea for ports Message-ID: <407B828F.1000600@pacific.net.sg> In-Reply-To: <20040413054109.D730D43D1F@mx1.FreeBSD.org> References: <p0602040cbca10a7dbe52@[128.113.24.47]> <p0602040dbca11349ce03@[128.113.24.47]> <407B6B43.2050507@pacific.net.sg> <20040413042929.GA24603@xor.obsecurity.org> <407B780F.5030102@pacific.net.sg> <20040413054109.D730D43D1F@mx1.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Robin Schoonover wrote: > On Tue, 13 Apr 2004 13:18:07 +0800, Erich Dollansky wrote: > >>Hi, >> >>Kris Kennaway wrote: >> >>>On Tue, Apr 13, 2004 at 12:23:31PM +0800, Erich Dollansky wrote: >>> >>> >>>>It would be real helpfull to users if the package or port system would >>>>be able to automatically overcome this problem with installing the >>>>needed version in a way that the installed versions stays intact. >>> >>> >>>Take a look at the portupgrade port, I think that's what you're trying >>>to describe. >>> >> >>If I understood portupgrade right, it upgrade a port but it still does >>not allow to keep the old version in parallel allowing one application >>using the old one while the other application uses the new one. > > > That's rather difficult to do. The biggest problem you hit right away is I know that this is a challenging task. > a port will (usually) conflict with itself. In other words, all the > versions will want the same files in the same place. So in order to fix > this properly, you'd have to have separate places for each file (or > different file name). Then you need some way for application x and > application y which each depend on your port of multiple versions to use > the port version you want them to. > There will be the need for a central version manager. All versions are stored on different place. The central version manager tells new packages where the requested versions are stored. A system like this would overcome all problems you could when moving from GNOME 2.4 to 2.6. You could keep and even work in 2.4 while 2.6 is installed. You then have the chance to start each version direclty or you start the default version. Of course, the central version manager must also know which version is the default version of each package the user wants to use. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?407B828F.1000600>