Hi All,
Perhaps I should have explained better at the outset the mechanism
that RUKS employs to ensure RPM database coherency, but I didn't expect
interest to focus solely on it! :) Anyhow, some valid concerns have
been raised and I will attempt to address them below and hopefully
receive more useful feedback (thanks for all so far!):
If we start from the point of having a full package installed for
Foo 2.1; when Foo 2.2 is released it is packaged as per normal, then the
two full packages are fed to RUKS; here's what it does:
* Compares the packages to find all files that have changed
between releases
* Finds all new files since the previous release
* Finds all redundant files from the old release
* Writes a .spec file (based on template) that:
* Implements the same 'Name' as the full .rpm (so a -q
--provides will return the same name 'foo')
* Grabs all new and changed files
* Writes a simple script to 'rm' and then 'touch' all redundant
files (upon installation of the .rpm package: this is done with a %post
script)
* Migrates all %pre %post %preun %postun %triggerin %triggerun
%triggerpostun scripts from the latest .rpm to the new .patch.rpm file
* Migrates all 'Requires' directives from the latest .rpm to
the new .patch.rpm. ~Also~ (and this is key) it adds a Requires for the
~old~ version of the package.
* Uses the .spec to create a package, labelled and versioned as
Foo-2.2.patch.2.1-1.i386.rpm
The effect of the above is that once Foo-2.2.patch.2.1-1.i386.rpm is
installed (with -ivh --replacefiles) we have a situation where the
database thinks you have two instances of a full package that provides
'Foo' installed (similar to having two 'kernel' packages of different
version installed). The difference being of course that the newer
package 'clobbers' the files of the older (which RPM doesn't 'realise')
and that the newer package ~depends~ on the older package (in other
words, you can't uninstall the older package without using --nodeps, a
situation that will potentially break stuff even for normal packages).
Also, all of the files that the RPM database expects to find on the
filesystem are still there (although some are 'empty' files, and will
thus fail md5 checks). Of course the older packages can no longer be
verified for correctness with --verify, because RPM doesn't 'know' that
the files have changed. Finally, because all of the patches are in the
same 'stream' as the main package (they all provide 'foo'), if you
decide to install a full package again (because something is broken, or
whatever), when you install Foo-2.3-1.i386.rpm with -Uvh, RPM will
remove all previous .patch.rpm packages as well as the previous full
package prior to installing Foo-2.3, so things are kept nice and clean.
The downsides are of course that as mentioned you can no longer use
--verify on anything but the latest package, with doesn't necessarily
cover all the files the program uses. The upside is that you can
theoretically, starting from a full install, just apply patches forever
(my example screenshot on freshmeat.net shows Battle for Wesnoth
installed full at 0.7, then patched to 0.7.10, then patched to 0.7.11,
then patched to 0.8, then running successfully).
Please let me know how this looks and what solutions anyone can see
for some of the problems mentioned.
Thanks heaps, I value your responses,
D
On Thu, 2004-08-12 at 21:20, johannes.grumboeck@xxxxxxxxxxxxx wrote:
>
>
> Hi,
>
> I think the approach from Darryl is a good way to do patches as long as rpm
> can't do it.
[...]
--
Darryl Dixon <esrever_otua@xxxxxxxxxxxxxxxxxxxxxxxxxx>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
