[gobolinux-devel] Re: Comments on Unmanaged and third party modules

[Lucas C. Villa Real]

On 8/1/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:

> > > Why does the file Resources/UnmanagedFiles exist? Is there an idea that
> > > the files should be removed when the program is removed/disabled?
> > > Otherwise one could just copy from Resources/Unmanaged to / or am I
> > > missing something? Maybe it is there for future uses?
> >
> > It exists for control by Compile. After building, Compile checks the
> > leftovers in the sandbox and only accepts leftovers accepted in the
> > UnmanagedFiles list. This way, we can control the build and not have
> > accidental leftovers end up in the package.
> >
> Ok, that makes sense.

I'm preparing a recipe for the development release of SVGALib here,
and this is the list of files/directories affected by depmod,
including the kernel module itself:

System
System/Kernel
System/Kernel/Modules
System/Kernel/Modules/2.6.16.14-Gobo
System/Kernel/Modules/2.6.16.14-Gobo/modules.usbmap
System/Kernel/Modules/2.6.16.14-Gobo/modules.inputmap
System/Kernel/Modules/2.6.16.14-Gobo/modules.symbols
System/Kernel/Modules/2.6.16.14-Gobo/kernel
System/Kernel/Modules/2.6.16.14-Gobo/kernel/misc
System/Kernel/Modules/2.6.16.14-Gobo/kernel/misc/svgalib_helper.ko
System/Kernel/Modules/2.6.16.14-Gobo/modules.isapnpmap
System/Kernel/Modules/2.6.16.14-Gobo/modules.alias
System/Kernel/Modules/2.6.16.14-Gobo/modules.ccwmap
System/Kernel/Modules/2.6.16.14-Gobo/modules.dep
System/Kernel/Modules/2.6.16.14-Gobo/modules.ieee1394map
System/Kernel/Modules/2.6.16.14-Gobo/modules.pcimap

How are you dealing with the kernel release when listing the files on
Unmanaged? Is it allowed to use variables inside it?

> > > About third party modules. When thinking about it, shouldn't
> > > ${target}/Shared/Linux/ThirdPartyModules/${appname} be a better location
> > > then ${target}/Shared/Compile/${appname}?
> >
> > Don't think so, because that would be a modules-specific path, and the
> > approach I suggested hints at turning this into a more general
> > "recompilation interdependency" mechanism. And the idea was, more
> > precisely:
> >
> > ${target}/Shared/Compile/${parentapp}/${childapp}

So, is this enough?

pre_link() {
    mkdir -p $target/share/Compile/Linux
    touch $target/share/Compile/Linux/$appname
}

We could add a flag "has_kernel_module=yes" to make it happen
automatically, but I'm a bit reluctant on adding new flags.

> > One thought: you probably won't want to write the kernel version
> > explitictly in the UnmanagedFiles entries. One way to solve this would
> > be to use paths like:
> > /System/Kernel/Modules/Current/...
> > but then it's a good thing to make sure /S/K/M/Current is sane. We can
> > tweak Compile to ensure this link is correct before handling unmanaged
> > files.

I think this answers my previous question. It worked fine here.

-- 
Lucas
powered by /dev/dsp