lkml.org 
[lkml]   [1998]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
important...

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
patches...

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 majordomo@vger.rutgers.edu


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans