ltib
[Top][All Lists]
Advanced

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

Re: [Ltib] Special tag localdir_nobuild causes LTIB to go to the config


From: Stuart Hughes
Subject: Re: [Ltib] Special tag localdir_nobuild causes LTIB to go to the config screen.
Date: Fri, 04 Dec 2009 14:27:45 +0000
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi Aaron/Olivia,

I've been thinking about this a little more (you have similar related issues I think).

On common question that arises is whether or not the PKG_KERNEL_LEAVESRC should be transient.

I believe it should because the principle is that when you install an ISO based LTIB image it should not build anything for the target image on the first ./ltib run, all it should do is re-populate the rootfs image based on the pre-built binary rpms.

Given this, if you then for example enable a kernel module from the config system, this will set the transient flag: PKG_KERNEL_LEAVESRC This change of state will be picked up by LTIB and cause:

* the kernel to unpack, build and keep the built source directory
* the module itself to build
* on exit the transient flag PKG_KERNEL_LEAVESRC

On the other hand, if you were to not clear the PKG_KERNEL_LEAVESRC in the .config for the ISO image, and you then enabled a module in the config system, this would set the already set PKG_KERNEL_LEAVESRC. As there is no change of state, ltib would not know to unpack the kernel sources.

Notwithstanding this, there may be other bugs in this area, but to investigate I need a very simple (bullet points) test case I can understand.

Regards, Stuart

FYI, here's a run I did where I enabled the helloword module on a system that had already built the kernel but had no source code unpacked:

Processing platform: A&MLtd Adder MPC875 PowerPC board
========================================================
using config/platform/qs875s/.config
PKG_KERNEL_LEAVESRC has changed, kernel-2.6.16-875 needs a rebuild

Processing: fake-provides
===========================

Processing: kernel-2.6.16-875
===============================
Build path taken because: spec file newer than rpm,



Stuart Hughes wrote:
Hi Aaron,

Thanks, I'll take a look and think about this one and the implications.

Regards, Stuart

address@hidden wrote:
Hi Stuart.

I think there's a comfort that the configuration used to create the BSP is
the same configuration that is presented to the user when installing the
BSP. If the user wants to do a "./ltib --force" right away then it should
be the same type of configuration and build that created the BSP.  That's
why I think the transient flags should not be affected in the release
process.  I'm not a Perl programmer, so for sure this is not an elegant
approach, but this patch is simple and works for me with both localdir and
localdir_nobuild special tags.  Aside from preserving the configuration,
it ensures that the kernel is not rebuilt in the case we discussed.


Thanks,

Aaron

Hi Aaron,

You have some points, however transient flags should not be relied upon
for installs.  The most important IMHO you make is the unnecessary
kernel build on install, this is not meant to happen.  However your
concern about rebuilding the kernel module should not be an issue as if
the module builds, it will should unpack and build the kernel.

This a real corner case and I doubt I will have time to look into it in
the immediate future.  Could you try to come up with a patch that
implement what you need (with the minimum change of behaviour).

Regards, Stuart

address@hidden wrote:
Hi Stuart.  I know this thread is from a while ago, and that this is
probably a minor issue.  I just thought I'd mention that I think it
might
be more correct to avoid clearing these transient configuration flags
(*WANT_CF and *LEAVESRC) when constructing a release or test release
BSP.

The thing is that even if I have a "select PKG_KERNEL_LEAVESRC" line
somewhere, or otherwise have it configured, it will get cleared with the
"./ltib -m clean" line in bin/Ltibrelease.pm when building a release.
Now
that the fix we worked on is present, the localdir_nobuild tag happily
does not clear the transient flags automatically, but other tags such as
localdir will.  This means that the configuration used to construct the
BSP will differ from the configuration of the BSP when it's being
installed from the iso (if any of the *WANT_CF or *LEAVESRC flags are
set
to 'y' in the default configuration) for all release tags except
localdir_nobuild, and I think this is a little inconsistent.  I believe
that the configuration that is present at the time the iso BSP is being
built should be the equivalent configuration when the iso BSP is being
installed.

Particularly bad is the way the localdir special tag is working right
now.
 Since I have a kernel module that depends on the kernel sources being
unpacked, I have my select PKG_KERNEL_LEAVESRC line in the package.lkc.
I
go to make a test release, and this builds the kernel binary RPM as
expected, but after it's built, the LTIB script clears
CONFIG_PKG_KERNEL_LEAVESRC in the .config file that is distributed with
the BSP.  When the user goes to install the BSP from the iso with "cd
non-*; ./ltib", the kernel package is actually automatically rebuilt
because there is a file .config.old that has
CONFIG_PKG_KERNEL_LEAVESRC=y,
and this differs with the .config file.  So, in effect, it rebuilds the
kernel binary RPM unnecessarily, but on top of that, it clears the
kernel
source when it's finished, because in the new .config file
CONFIG_PKG_KERNEL_LEAVESRC is not set.  Supposing a user wants to force
a
rebuild of the kernel module at this point, the kernel source will not
be
available in the BUILD directory.

Perhaps it might work for only the "./ltib -m clean" operation to avoid
clearing transient flags, and then these flags will persist through this
call, and be present in the same state in the BSP as they were to build
the BSP.

What do you think?

Aaron

Hi Aaron,

PKG_KERNEL_LEAVESRC is meant to be a one-shot as once unpacked the
source will remain and so there's no need to keep the flag enabled.

If you package needs the kernel source unpacked it should be selecting
PKG_KERNEL_LEAVESRC rather than relying on manually setting this in the ./ltib -m config session. Take a look at config/userspace/package.lkc,
for example:

config PKG_HELLOWORLD_MOD
     depends CAP_HAS_MMU
     select PKG_KERNEL_LEAVESRC
     bool "hello world module example"
     help
         simple hello world kernel modules example

Regards, Stuart


address@hidden wrote:
Hi Peter and Stuart. Working with my kernel module is precisely where
this gave me a little trouble.  I understand that you need the kernel
source unpacked for a kernel module package. My question was why this
is
a one-shot or transient variable.  The area that it was giving me a
few
problems was after creating an iso release, the build and installation
of
the BSP onto another machine. Using `./ltib` I would attempt to build
the
whole project (host and target packages), and I would get stuck on the kernel module package because my kernel source would not remain in the
BUILD directory.  This was because the PKG_KERNEL_LEAVESRC=y that I
had
put in place earlier was getting cleared automatically by a call to
`./ltib` when building the iso. Since I was running into this sort of
problem, I was wondering if there is any beneficial reason for having
the
LEAVESRC variable as a one-shot or transient variable.  It seems like
if
you have the source out for a particular package, and then you wanted
to
get rid of it, you can just remove it, and change the configuration to
comment out any variables like PKG_KERNEL_LEAVESRC if necessary.
Updating
the date/time stamp on my config/platform/${board}/.config file does
not
force a rebuild of the kernel for me.

One to thik about is a seperate package that builds a kernel module
(like PKG_HELLO_WORLD_MOD).  It needs the kernel source to remain so
it
can use the kernel build structure/headers to create a module that is
loadable by the kernel....
Hi Aaron,

Once source code is blown out and left (with LEAVESRC) it will stay
there. nothing will remove it until you do manually, so the flag only
needs to be transient.  The need for this is as Peter says, some
packages (like kernel modules) need access to the the real built
kernel
sources.

--leavesrc --force should leave all the sources unpacked.  This is
generally speaking a bad idea.

Thanks for the patch.

Regards, Stuart


_______________________________________________
LTIB home page: http://ltib.org

Ltib mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/ltib





_______________________________________________
LTIB home page: http://ltib.org

Ltib mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/ltib



------------------------------------------------------------------------

_______________________________________________
LTIB home page: http://ltib.org

Ltib mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/ltib


_______________________________________________
LTIB home page: http://ltib.org

Ltib mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/ltib





reply via email to

[Prev in Thread] Current Thread [Next in Thread]