Mailinglist Archive: opensuse-features (188 mails)

< Previous Next >
[openFATE 309578] Better maintenance of src.rpm changes
  • From: fate_noreply@xxxxxxx
  • Date: Fri, 21 May 2010 15:28:20 +0200 (CEST)
  • Message-id: <feature-309578-3@xxxxxxxxxxxxxx>
Feature changed by: Michal Vyskocil (mvyskocil)
Feature #309578, revision 3
Title: Better maintenance of src.rpm changes

Requested by: Michal Vyskocil (mvyskocil)
Developer: (Novell)
+ Developer: (Novell)
Partner organization: openSUSE.org

Description:
During a SUSE development, we are often using upstream source rpms. The
most notable example is jpackage.org - a source of almost every of our
Java package. But importing of jpackage.org 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):
openSUSE.org: 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 jpackage.org. 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:
https://features.opensuse.org/309578

< Previous Next >
List Navigation