[lkml]   [1998]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Why from there? A rethink...
    Hi Pierre, Linus.

    Having thought further about this problem, I see that it isn't
    necessarily a problem in the first place since they are dealing with
    two different scenarios that do not need to intersect:

    1. The full kernel source tarball DOES need to include the kernel
    version number to prevent problems caused by old files that are
    still lying round. This is the point that I was addressing in my
    earlier plea.

    2. The kernel upgrade patch files DO NOT need to include the
    kernel version number since they are by their nature designed
    to be applied to an existing kernel source tree, and each
    patch file needs to be installed in sequence, so any suchlike
    excess files will be deleted by the correct installation of
    the relevant patch file for the version where it was deleted.

    Naturally, if somebody upgraded by installing the patches rather than
    by grabbing a new kernel source tree tarball, they would be able to
    either copy the existing tree to a new directory and patch that, or
    alternatively to just patch the existing tree, and neither would
    result in the problems I've been meeting from my clients. The problems
    can ONLY occur when a new full source tarball is extracted on top of
    an existing tree...

    I therefore repeat my plea: PLEASE PLEASE PLEASE use the FULL version
    numbered base directory name in the full source tarballs. It would
    also be appreciated if you could include the relevant symlink from
    ./linux to ./linux-?.?.? to update that as well, but that isn't so

    Best wishes from Riley.

    /* Original message follows */

    Hi Pierre, Linus.

    >> I'd second that, apart from a little question: if I apply
    >> patch-2.1.102 to linux-2.1.101, is there a way to change the
    >> directory name to linux-2.1.102? If not, I can see why it is named
    >> 'linux'.

    I presume the original of the above is later in my inbox since I
    haven't seen it yet...yep, seven messages after this one...

    > Bingo.

    There IS a simple solution, although it's a little more work for the
    people creating the upgrade patches, which is to put the correct paths
    in them. I don't have one to hand, so the following is a fabricated
    part-patch to upgrade from kernel 9.8.7 to 9.8.8 that should do it:

    Q> --- linux-9.8.7/drivers/char/serial.c Thu May 14 00:09:12 1998
    Q> +++ linux-9.8.8/drivers/char/serial.c Thu May 14 00:09:19 1998

    Note that the FIRST element of the path shown DIFFERS between the two
    paths, and my understanding of how patch works indicates that the
    above would result in it taking the contents of the existing file as
    labelled by the --- line and copying it to that named by the +++ line
    with any patches indicated being made.

    This would mean that every kernel upgrade patch would need to name
    every file in the old kernel that was also in the new kernel for the
    patches to work, hence the extra work for the people making the

    NOTE that I have not yet tried the above sine the system I'm on at the
    moment isn't able to do so - this system has the advantage that I
    don't have to pay for the net connection though. However, I will try
    it out, and comment on it - and if patch doesn't currently support
    that, perhaps a mode could be added where it does...

    Best wishes from Riley.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.021 / U:14.688 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site