[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Binary RPM patch packages versus Windows SP style
- From: Robert Vojta <robert vojta mandrake cz>
- To: rpm-list redhat com
- Subject: Binary RPM patch packages versus Windows SP style
- Date: Thu, 26 Aug 2004 22:58:03 +0200
Hallo all,
this is reaction to the email with this subject "Request for comments on
binary RPM patch packages".
My opinion is that this idea is good but binary diffs are too difficult to
implement without any side effects like patch packages are allowed to be
in the system even if we are removing original package, etc.
Let me introduce different idea about "incremental" updates. These packages
will not contain binary diffs, but full and modified files only. RPM need to
be enhanced by this:
- new tag
example: IncrementalUpdateRequires: x.y.z
- new tag for "ghost" files, files that RPM should use from the already
installed packages, something like %ghost
example: %donotupdate /usr/bin/xcalc
- rpmbuild script modifications (ability to build these packages)
Full vs incremental RPM packages cycle should be done in this way:
- Mandrakelinux 10.0 release (full RPM packages)
+ updates for 10.0 (incremental RPM packages)
- Mandrakelinux 10.1 release (full RPM packages)
+ updates for 10.1 (incremental RPM packages)
- ...
And the incremental package will install in this way ...
- installed via new switch, like update
- %donotupdate files will be used from the already installed package
- missing files will be removed
- package info will be update, so just new package will be in the system
Difference between binary diff and incremental package is in these things:
o package version
- for binary diff, you need exact package version and if you want to
update from A to C, you have to proceed with A->B and B->C and it means,
that you need to place all binary diff packages between A and C onto the
ftp site
- for incremental package, you need release package version or higher, so
you can easily proceed with update from A to E for example
o package size
- binary diff package is smaller than incremental, but the integrity is
not good as incremental package
o package making
- incremental package will be always created against the distro released
package even if we will have newer version here, example:
MDK 10.0, package A version 1.0
- update 1.1 - incremental against 1.0
- update 1.2 - incremental against 1.0
- update 1.3 - incremental against 1.0
You can use latest package and update 1.0, 1.1 or 1.2 version. This is
not possible with binary diff.
- I know that the package will grow, but when the size will be critical,
new distro version will be here and full RPM packages will be released
and this cycle will start again.
This is rough idea how to proceed with incremental updates. Or we can do
incremental update package with binary diffs for all versions. It means that
1.3 version will contains binary diffs for 1.0->1.1, 1.1->1.2, 1.2->1.3 and
you can update all versions from version 1.0. Question is if the final size
will not be bigger than my incremental package.
All comments welcome.
R.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]