Mailinglist Archive: opensuse-features (187 mails)

< Previous Next >
[New: openFATE 309578] Better maintenance of src.rpm changes
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 20 May 2010 16:52:11 +0200 (CEST)
  • Message-id: <feature-309578-1@xxxxxxxxxxxxxx>
Feature added by: Michal Vyskocil (mvyskocil)

Feature #309578, revision 1
Title: Better maintenance of src.rpm changes

Requested by: Michal Vyskocil (mvyskocil)
Partner organization:

During a SUSE development, we are often using upstream source rpms. The most
notable example is - a source of almost every of our Java package.
But importing of src.rpm we create a fork of this package and it
is not possible to maintain our and future upstream changes. Everything needs
to be done manually, which is horribly slow and also error prone apporach.

There is a better solution based on patch queues - SUSE changes are considered
as a set of patches on top of the upstream sources. This method has many
advantages - like sharing of our changes with upstream is piece of cake,
updating to the new upstream version is simple - just pop all patches and try
to recreate them to newest version.

upg is the tool try to smoothly intergrate three different systems into one -
osc, git and stg to make this concept easy to use. It manages patches using
stg, it is well integrated into BuildService using osc and comes with a few
interesting concepts, which will make work with patches more reasonable:

 * scratches - patches created by simple script - they are never "popped",
simply recreated again, so they never failed  * heuristics - sometimes patches
fails only because PatchXY: number is changed in new upstream version, so upg
would be able to fix that  * changes - it's a pain for each versioning system,
but upg deal with it and try to have them in a good state

What is done:

upg already exists in very raw version with a basic concept implemented, tested
and working (netbeans 6.8 update has been done using this tool).

What needs to be done:

A public release, implemented configuration system, more heuristics and add
more tests than now - yes and also some documentation will be necessary

Business case (Partner benefit): Why do we want this? Well the most probable user is me - I'll use
it for a big automation of my work with a But this tool can also
change a concept of rpm packaging as it is done today. Nowadays we maintain a
lot of packages in different code streams and projects, because every one have
their own processes, needs and requirements. Using this approach we might be
able to reuse an effort of some other projects and be up-to-date with them.
Also will be able to share our improvements more easily. The second big use
case of this system is an ability of maintain our own forks (or branches) of
packages improved for specific purposes.

openSUSE Feature:

< Previous Next >
List Navigation