I needed to be able to build a bit more complex set of rpm files than
the make rpm function allowed. Attached is a patch that will replace
the scripts/mkspec file with a perl program that generates a bit better
spec file, the change to the top level Makefile that will use perl not
bash for mkspec and a file for the Doc... directory explaining the changes.
If there is anyone using the make rpm could take a look at this and let
me know if it works with your build. I have tested this under a production
build based on 2.4.17 and a build with default configuration under 2.5.1
(I can't build any of my standard configuration for 2.5.1 due to buslogic
dirver problems) and it does what I intended it to.
the attachment is a gziped patch file made from /usr/src with diff -urN
--
It is MDT, Inc's policy to delete mail containing unsolicited file attachments.
Please be sure to contact the MDT staff member BEFORE sending an e-mail with
any file attachments; they will be able to arrange for the files to be received.
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please advise [email protected]
<mailto:[email protected]>.
Philip W. Dalrymple III <[email protected]>
MDT Software - The Change Management Company
+1 678 297 1001
Fax +1 678 297 1003
On Fri, 4 Jan 2002 15:05:37 -0500 (EST),
[email protected] wrote:
>I needed to be able to build a bit more complex set of rpm files than
>the make rpm function allowed. Attached is a patch that will replace
>the scripts/mkspec file with a perl program that generates a bit better
>spec file, the change to the top level Makefile that will use perl not
>bash for mkspec and a file for the Doc... directory explaining the changes.
>
>If there is anyone using the make rpm could take a look at this and let
>me know if it works with your build. I have tested this under a production
>build based on 2.4.17 and a build with default configuration under 2.5.1
>(I can't build any of my standard configuration for 2.5.1 due to buslogic
>dirver problems) and it does what I intended it to.
In kernel build 2.5 the make rpm target does not exist. kbuild 2.5
builds the kernel and modules, installs the kernel, modules, System.map
and .config, that is _all_ it does. Extra tasks like updating
bootloader files or building a package using the packaging method of
the month are _not_ part of kbuild 2.5. Every user wants to do
something different with bootloaders and packaging, there is no "one
size fits all" script.
Having said that, kbuild 2.5 is extensible. You can specify additional
targets and commands to do whatever special processing the user wants.
I have no problem with kbuild 2.5 shipping /sample/ scripts to do extra
processing, but it will not invoke them directly. Users copy the
sample code to their own directories and change it, then tell kbuild to
execute the copy that does exactly what this user wants. From
Documentation/kbuild/kbuild-2.5.txt:
ADDITIONAL TARGETS AND COMMANDS
Some users will want to execute additional commands as part of kbuild. In
particular users who generate kernel packages will want to run their own
commands after make install. Instead of polluting the kbuild Makefiles
with rules that have nothing to do with kernel building, kbuild 2.5
supports user defined additional commands, using variables ADD0 through
ADD9, with the corresponding ADD[0-9]_DEP and ADD[0-9]_CMD. A command like
make ADD0=pkg ADD0_DEP=install ADD0_CMD='my-package-script' pkg
Will make target 'pkg', which is defined by ADD0. It has a dependency
(ADD0_DEP) of install so the install process runs first. After install has
completed, command my-package-script (ADD0_CMD) is run. The command can be
shell commands separated by ';' but will normally be a distribution
specific script. The command has access to all the config variables plus
the variables that define the kernel, including KERNELRELEASE.
It is the responsibility of the packager to maintain their own scripts.
kbuild will not maintain scripts for every packaging manager used by every
distribution.
Because of the way that the .config variables are read by kbuild, you can
specify a CONFIG_ variable on the make command line and it will override
the value used by the makefiles. In general this is not safe because the
config values read during the compile stage are set by another mechanism so
overriding a config variable on the command line when that variable is used
in code will generate inconsistent results.
However there are some config variables that can be safely specified on the
make command line because they are only used by the makefiles. All these
variables start with CONFIG_INSTALL_, they define where the kernel,
modules, map, .config etc. are installed. Obviously a packaging system
will want to set some of these values on the command line. See the top
level Makefile.in for the current CONFIG_INSTALL_ variables.
On 5 Jan, Keith Owens wrote:
> On Fri, 4 Jan 2002 15:05:37 -0500 (EST),
> [email protected] wrote:
>>I needed to be able to build a bit more complex set of rpm files than
>>the make rpm function allowed. Attached is a patch that will replace
>
> In kernel build 2.5 the make rpm target does not exist. kbuild 2.5
> builds the kernel and modules, installs the kernel, modules, System.map
> and .config, that is _all_ it does. Extra tasks like updating
> bootloader files or building a package using the packaging method of
> the month are _not_ part of kbuild 2.5. Every user wants to do
> something different with bootloaders and packaging, there is no "one
> size fits all" script.
>
>
The reason for the improved rpm build process is not per say for distrubutation
builders; it is for users who have a number of systems to manage and don't want
to have non package things floating around.
That said it looks like the best thing for me to do might be to move the "make rpm"
function out of the Makefile and into a seperate script when kbuild 2.5 is
made live in the main line. The rpm build does not use the make system to
build first phase and after that is under the control of RPM itself.
I assume that the xconfig, oldconfig, config and mconfig are present in
kbuild 2.5?
What is the correct method to tell if 2.5 is live?
--
It is MDT, Inc's policy to delete mail containing unsolicited file attachments.
Please be sure to contact the MDT staff member BEFORE sending an e-mail with
any file attachments; they will be able to arrange for the files to be received.
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please advise [email protected]
<mailto:[email protected]>.
Philip W. Dalrymple III <[email protected]>
MDT Software - The Change Management Company
+1 678 297 1001
Fax +1 678 297 1003
On Mon, 7 Jan 2002 13:07:10 -0500 (EST),
[email protected] wrote:
>That said it looks like the best thing for me to do might be to move the "make rpm"
>function out of the Makefile and into a seperate script when kbuild 2.5 is
>made live in the main line. The rpm build does not use the make system to
>build first phase and after that is under the control of RPM itself.
>I assume that the xconfig, oldconfig, config and mconfig are present in
>kbuild 2.5?
Not mconfig, kbuild 2.4 contains the existing 2.4 CML1 targets plus the
new targets from CML2.
>What is the correct method to tell if 2.5 is live?
grep CONFIG_KBUILD_2_5=y .config