On Thu, Jun 28, 2001 at 11:16:30PM +0200, 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
Why are you using flavours here? AFAIK that is a hack that allows you to
have multiple builds of a kernel version installed on the same machine,
without any confusion about where to find the right modules for each
respective kernel build variant. So, AFAICS it would make no sense to
have a flavour named after the host.
What I do myself is to put the hostname in the kernel-image deb version
string. If you like, you can add the date to that as well:
The '3:' is an epoch. Read about it in the fm in $doc/kernel-package.
Also, it will not show up in the filename of the deb built, but the
epoch will be in the binary control file.
> 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).
Between calls to make-kpkg for different binary builds, you must do a
"make-kpkg clean", instead of just "make clean". The reason is to
force regeneration of the debian/control file, I believe.
- From: MaD dUCK <email@example.com>