[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: make-kpkg



On Thu, 28 Jun 2001, MaD dUCK wrote:
> 
> so i am almost down with make-kpkg, and have now set up a local server
> with a script so that i only have to type 26 characters on the
> terminal, then apt-get update && upgrade at each system to update the
> kernel. it's nice.
> 
> i have three questions, though:
> 
> (1) one thing i don't quite get yet is the revision stuff. i call my
> revision numbers "yyyymmdd.x" (like named zone file serial numbers),
> but isn't it that make-kpkg should increment the 'x' every single
> build? right now, i do
> 
>   make-kpkg clean
>   make-kpkg --arch_in_name --flavour <machine> --revision yyyymmdd.x
>     kernel-image
> 
> but that way, i specify the revision everytime. nevertheless,
> afterwards, i don't see it stored anywhere, so how should make-kpkg
> know the next time, what to increment? also, i have to run make-kpkg
> clean everytime since i am compiling for multiple machines. right now
> i help myself by setting the revision=`date "+%Y%m%d.%H%M`, which is
> perfect, but i'd still like to know how to do it The Right Way (tm).
> 
afaik, make-kpkg just does what you tell it, and has no system to
automagically increment the kernel revision. you might want to extend your
script to keep the last revision used in /var/run or something,
e.g. (in bash)

lastversion=`cat /var/run/last_kernel_revision`
lastversion=$[lastversion+1]
echo ${lastversion} >/var/run/last_kernel_revision

make-kpkg --revision `date "+%Y%m%d.%H%M"`.${lastversion}

you really should be using epochs to make sure your kernel package is
always treated as newer than the official packages, by prepending the
revision with a number and a colon, e.g. 3:`date
"+%Y%m%d.%H%M"`.${lastverision}

you shouldn't need to use an epoch >3. see the debian packaging manual for
the nitty-gritty about epochs.

> (2) --arch_in_name   works for the i486 machine, yielding a filename
>   kernel-image-2.4.5-embryo-i486_20010628.2129_i386.deb, but
> compiling it for either the pentium I, the pentium II, the AMD K6-2,
> or the Athlon yields a mere
>   kernel-image-2.4.5-seamus_20010628.1453_i386.deb.
> 
> What gives?
> 
i believe that you are confused about the terms "architecture" and
"cpu". "arch" only specifies the family of processor, not the specific
type. and the pentium/ppro/p2 are all members of the i386 family. you
might want to stick the cpu type in the flavor or revision and drop
--arch_in_name if you really care about it.

> (3) i use a mixture of stable/unstable/testing. i figure that i have
> to compile everything on the lowest common denominator, so i use a
> stable machine. but i think that it is bad (performance, security) for
> me to run a kernel compiled on stable on a system that runs testing or
> unstable. is there a good way to use one system to compile for all
> three releases?
> 
it really doesn't matter that much. the kernel doesn't depend on any
external libraries, just the build tools, e.g. gcc, binutils, as86 (on
i386) and lex/yacc. you might get better performance with a newer
gcc/binutils, but it's really not a big enough performance diffence to
worry about.



Reply to: