Hi Christian,
let me just give an example to illustrate the patch szenario.
original install office-1.0.0 looks like this:
core1-1.0.rpm contains the file libvcl680.so.1
core1u-1.0.rpm contains the symlink libvcl680.so -> libvcl680.so.1
first patch to office-1.0.1 looks like this:
core1u-1.1.rpm contains the file libvcl680.so.2
and
contains the symlink libvcl680.so -> libvcl680.so.2
second patch to office-1.0.2 looks like this:
core1u-1.2.rpm contains the file libvcl680.so.2
and
contains the symlink libvc680.so -> libvcl680.so.2
you can upgrade core1u through the regular rpm upgrade mechanism, it
upgrades the symlink and provides a new file.
After the first patch the installation contains libvcl680.so.1,
libvcl680.so.2 and the symlink libvcl680.so pointing to libvcl680.so. In
the second patch libvcl680.so.2 is already part of the patch, wether it
needs a new revision or not, therefor in all patches the name
libvcl680.so.2 remains constant and you stay with 2 libvcl680so.x files.
You don't need a postinstall action to provide the symlink, it's just
part of the package, pretty much the same as any regular file.
The symlink mechanism has been established for shared libraries and a
few other files. Files not handled through softlinks can be upgraded by
providing a complete new revision of the rpm they are in. To facilitate
that we have divided OpenOffice.org into a set of smaller rpms that
(hopefully) group patch prone files together.
- Christof
Christian Lohmaier wrote:
Hi *,
On Mon, May 23, 2005 at 02:00:37PM +0200, Christof Pintaske wrote:
Christian Lohmaier wrote:
[...]
So to sum up again (please add your pros/cons to that list esp. to the
patch-rpm method since I don't know that myself):
Symlink-method:
Cons:
* leaves the old files on the harddisk (could be removed by the patch
and the original package could specify "missingok")
* needs a postinstall-script to update the symlink
nope, the symlinks and the files they point to are provided in different
rpms.
Exactly this is the reason why it has to be mapped to the new file.
Given you have a link "lib -> originallib" and now install "newlib", you
somehow have to modify the link "lib" to point to "lib -> newlib"
The symlinks-1.0.rpm is upgraded with somethink like a
rpm -U symlinks-1.1.rpm
whereas the file is provided in a completely_different-1.0.rpm
So to patch OOo you'll always have to install/update two packages? The
symlink-rpm and a real-patch-rpm? So a symlink-package would be part of
the initial install as well?
And that symlink-rpm will always "hardcode" the symlink to the file from
the real-patch-rpm?
* may need some work in OOo to make it work with symlinked components
you probably don't want to have all files symlinked as this clutters
your installation.
True, but see the Help and images.zip
Not having those as links mean either:
* no updates possible or
* those modules have to be yet in another package.
Pros:
* no command-line parameter to force the installation necessary
* can tell whether a patch is installed by doing a ls /path/to/OOo
* package can be uninstalled w/o problems (when original file is not
removed)
when removing the package you need to reinstall the old symlink package.
Hmm. Downgrading requires a rpm-commandline switch.. What I was thinking
of is a postuninstall script that points the link back to the original
file - but if patches are always done using two packages...
"just-replace-the-file"-method:
Cons:
* this is not much better than installing just the file by any random
installation mechanism
I'd not say that. You can still use rpm to query where the file came
from (you can't do this by copying the files by hand)
And even more important: You can check whether the patch is already
installed (by querying for the patch-package). You can't do that with
any random method.
[...]
ciao
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
