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

[aaron]

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-release-config-fix.patch
Description: Binary data