Re: New kernel-source-2.6.7 upload ?

[Sven Luther <sven.luther@wanadoo.fr>]

On Fri, Aug 06, 2004 at 10:33:37AM +0200, Jens Schmalzing wrote:
> Hi,
> 
> Sven Luther writes:
> 
> > So, i still don't understand what is broken.
> 
> Consider a patch that creates a single file containing a single line:
> 
> +foo
> 
> You publish this as the first revision, resulting in the patchset:
> 
> patch-1:
> +foo
> 
> You realize you should have applied a different patch:
> 
> +bar
> 
> So you want to publish a second revision containing the patchset:
> 
> patch-1:
> +foo
> 
> patch-2:
> -foo
> +bar
> 
> If you just replace the patch, you will break the path between the
> first and the second revision, because you get:
> 
> patch-1:
> +bar
> 
> patch-2:
> +bar

Ok, that is fine. My question is the following. you have :

patch-1:
+foo

patch-2:
-foo
+bar

Now, you have two versions of the kernel-source :

source-1:
normal+foo

source-2:
normal+bar

The question is : 

if you have source-1 installed, but both patch-2  and tree-2, you can still
get both the source-1 and source-2 if you apply the patch, since the source
contain exactly the same thing (the pristine upstream source minus the
non-free stuff), and the patches you chose to apply (or not).

If the arch package now was built with patches on top of patch-1, and thus
break with the patch-2 application, then it depending on whatever version of
tree (> to the one it was built with) will work all the time, even if
additional patches get applied to the source package.

Now, the real problem is if security updates happen, those will usually happen
in the source/patch/tree package, and thus you have to :

 1) rebuild the arch patch package anyway, so as to obtain the kernel-image
 that it applies to.

 2) upgrade the build-dependency on source/patch/tree so as to forbid builds
 older than the security updates.

 3) change your per-arch patches if they got broken by the security or normal
 updates.

With the per patch application mechanism you didn't like, you have to
additionally : 

 4) Upgrade the version of the patch-# you are using.

This is the only additional constraint, and you get the benefit that the per
arch package remains buildable at all time, even if a new kernel-source got
uploaded in the meantime.

Let's take a concrete example, we migrated the pegasos patches from the
powerpc package to the kernel-source one. In kernel-source 3 the pegasos patch
was not, but it got added for kernel-source 4. The pegasos patch was in
powerpc 3 and 4, but got removed from 5.

The chronology was as follows : 

  kernel-source 3 uploaded. (does not contain pegasos patches)
  powerpc 3 uploaded. (does contain pegasos patches)
  powerpc 4 uploaded. (does contain pegasos patches)
  kernel-source 4 uploaded. (does contain pegasos patches)

    => At this time, the powerpc package in the archive is unbuildable, since
    the pegasos patches in powerpc conflict with the kernel-source one (which
    may or may not be the same one).

  powerpc 5 uploaded. (does not contain pegasos patches)

    => Everything is fine again.

If we had the per patch level thingy, we could say that powerpc 3 and 4 needed
the kernel-source patchlevel 3, and it would not break between the time that
kernel-source 4 is uploaded and the time that powerpc 5 is uploaded. (Ok,
sure, you uploaded them almost together, but this will not always be the
case).

You are claiming that this poses problem, and i may be stupid, but i am
failing to understand what the problem may exactly be.

Friendly,

Sven Luther