On Sat, 9 Sep 2000, Daniel Phillips wrote:
> Simon Huggins wrote:
> > On Thu, Sep 07, 2000 at 08:46:56AM +1100, Keith Owens wrote:
> > ... and a few more times recent weeks ...
> >
> > > <rant>
> > > Why don't you look in linux/Documentation/Changes? That file exist
> > > precisely to stop repeated questions like this on the linux kernel
> > > developers list.
> > > </rant>
> >
> > Because the file just lists versions you need. It doesn't say "since
> > version x.y.z you need a newer version".
> >
> > Why not make it easy on people and have a log something like:
> >
> > 2.4.0-testX-preY
> > Requires modutils-x.y.z otherwise you get error messages like
> > "blah blah blah"
> > Note you should no longer frobnicate the thingummie or bad
> > things will happen.
> > 2.3.whatever_it_was
> > You need to mount shm on blah.
> >
> > Now when you tell them to read this file it sticks and *next time* they
> > look there too.
> > Why?
> > Because it's a hell of a lot easier to work out what has changed from
> > one version to the next.
> >
> > It also means that people who ran earlier pre versions of 2.4 but didn't
> > upgrade in the mean time for one reason or another can find out what has
> > changed between the few versions of this file.
> >
> > Stuff like the shm stuff and the modutils stuff has generated a fair bit
> > of traffic. Having a step by step Changelog style file would help
> > people get it right the first time.
> >
> > Comments?
>
> I'd like to see a directory in the root of the kernel tree having the
> name of the kernel version. Any patch that breaks things writes a one
> or two line file into that directory. When it's time to release a
> kernel version you do the following:
>
> cat 2.4.0-testX/* >>Documentation/Changes
> rm -rf 2.4.0-testX
>
> Forgetting to do this rollup is ok, it doesn't hurt anything.
> Forgetting to include the change log entry in the patch is ok too -
> it's not any worse than the current situation.
>
> This approach gives us a way of annotating the important effects of
> patches that are actually applied.
>
> I can think of various arguments for not doing this or something like
> it, but the only substantive one I can think of is 'no, it would make
> it easier to work with the kernel', and I guess this is the argument
> that will be applied in this case. Disclaimer: I don't mind, in fact
> being an elitist is kind of fun.
This is similar to my patch-names patch, which lets you add components to
uname too. IIRC, it was rejected because it made things easier.
diff -uNr linux-2.2.0-pre6/Makefile linux/Makefile
--- linux-2.2.0-pre6/Makefile Wed Jan 6 17:01:15 1999
+++ linux/Makefile Tue Jan 12 17:31:33 1999
@@ -281,7 +281,10 @@
@mv -f .ver $@
include/linux/version.h: ./Makefile
- @echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver
+ @echo -n \#define UTS_RELEASE \"$(KERNELRELEASE) > .ver
+ @find -maxdepth 1 -name 'patchdesc.*[^~]' -printf '+%f' | \
+ sed -e 's/+patchdesc\./+/g' >> .ver
+ @echo \" >> .ver
@echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver
@echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver
@mv -f .ver $@
diff -uNr linux-2.2.0-pre6/patchdesc.names linux/patchdesc.names
--- linux-2.2.0-pre6/patchdesc.names Wed Dec 31 18:00:00 1969
+++ linux/patchdesc.names Tue Jan 12 17:30:49 1999
@@ -0,0 +1,7 @@
+This patch adds a simple method to identify patched kernels. Patches
+that include a file named 'patchdesc.*' in the top level source
+directory will cause the kernel to add the file extension to the
+version that is reported by uname(1). For instance, this file will
+result in the 2.x.x+name being reported.
+
+oxymoron@waste.org Jan 12 1999
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:12 EST