Mailinglist Archive: opensuse-features (318 mails)

< Previous Next >
[openFATE 309637] Expanded kernel-source
  • From: fate_noreply@xxxxxxx
  • Date: Wed, 2 Jun 2010 16:42:28 +0200 (CEST)
  • Message-id: <feature-309637-5@xxxxxxxxxxxxxx>
Feature changed by: Michal Marek (michal-m)
Feature #309637, revision 5
Title: Expanded kernel-source

Requested by: Michal Marek (michal-m)
Developer: (Novell)
Partner organization:

Create a "mirror" of the kernel-source repository
( that has the same commits
as kernel-source, but the trees are actual linux sources with the suse
patches applied. While this sounds easy and I have a working prototype
already, there are a few gotchas to solve:
* what to do with patches that do not apply (and with those that do
apply, but only with a specific version of patch(1))
* what to do with really ancient suse trees that where the patch series
was dependent on the architecture or flavor
* how to do this incrementally and automatically after each kernel-
source push
Also a nice feature would be to merge with the upstream branch whenever
the upstream version is updated, so that one has a single history to

Business case (Partner benefit): Easy browsing of the history, without having to decipher
two columns with plus and minus signs.

#1: Jan Engelhardt (jengelh) (2010-05-31 18:45:38)
To start with: an <architecture, flavor>-specific tree that is
# preexsting tree at .
find . ! -name .git -delete
unrpm kernel-devel.noarch.rpm
unrpm kernel-source.noarch.rpm
git add -A .
git commit
Then deal with getting rid of the architecture-specificness. This is
mostly done already, as there are barely patches that are architecture-
specific. (All those ppc patches also get applied to kernel-default.
Next up is flavor-specific, that's gonna be a big issue, because RT is
pretty much mutually exclusive with XEN currently.

#2: Michal Marek (michal-m) (2010-05-31 19:04:58) (reply to #1)
I had those +$arch patches.arch/foo.patch patches in mind. The last
offender was killed by 643042 in 2004 it seems. One option is to start
the history at this commit, because it was even before SLES9 branched.
Another option is a separate history for each architecture, which is a
waste IMO, the patch series has been unified for 6 years now. Yet
another option is to create arch-specific branches and merge them in a
smart way. That would be my favorite, but requires some work.
RT is a different topic, yes it used to live in the master branch
guarded for a while, but since then it moved to dedicated branches.

+ #3: Michal Marek (michal-m) (2010-06-02 16:42:20)
+ This is what I have so far:

openSUSE Feature:

< Previous Next >
This Thread
  • No further messages