Binary RPM patch packages versus Windows SP style

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux