Re: Custom kernel build - best way to generate a package

[Jan Kiszka <jan.kiszka@siemens.com>]

[re-adding the list]

On 2018-01-25 19:24, Benedikt Niedermayr wrote:
> Am 25.01.2018 um 13:56 schrieb Jan Kiszka:
>> On 2018-01-25 09:50, [ext] Jan Kiszka wrote:
>>> Hi all,
>>>
>>> as indicated before, I'm looking into providing a framework for isar to
>>> help users with building their own kernel packages from un-debianized
>>> kernel sources. I'm now scratching my head how to do that best. Options
>>> I'Ve found so far:
>>>
>>> 1. make bindeb-pkg (from upstream kernel)
>>>
>>>     Downside: currently requires patches to feed in missing runtime
>>>     dependencies of the generated package. Also, it seems this is not
>>>     designed to create full replacements of the standard debian kernel
>>>     packages. Might be an uphill battle on the long run.
>>>
>>> 2. Provide debian/ folder in isar so that dpkg_runbuild works
>>>
>>>     Question is here where to pick up the debian/ folder from. The
>>>     original debian kernel package? The version that Frank once
>>> create as
>>>     demo [1] (BTW, how was it created?)?
>>>
>>> 3. make-kpkg
>>>
>>>     Still unclear to me what pros and cons are here.
>> Just played with it, and it also generates packages that are not meant
>> to be replacements of the standard debian kernel - incomplete deps. At
>> least under jessie.
>>
>> Jan
>>
>>> Any comments / suggestions would be highly appreciated!
>>>
>>> Thanks,
>>> Jan
>>>
>>> [1]
>>> https://github.com/ilbers/linux/commit/b7ab449238b8e59943849a10c95d578aa01d70e7
>>>
>>>
> Hi,
> 
> 
>> 2. Provide debian/ folder in isar so that dpkg_runbuild works
> This would be my favorite one. Using a debian/ folder seems to be the
> most generic solution.
> 
> Because then we are able to use a generic class which creates debian
> packages in general for any kind of software package.
> 
> The  "make-kpkg" solution might work very good for the kernel itself....
> but only for the kernel. That represents a disadvantage for me.

Well, this case is about the kernel itself, only. The control files
needed to build the kernel are not reusable for other tasks.

> 
> Are there any proposals or ideas for generic "debianization" of software
> packages yet? I think when it comes to that point, we will realize that
> the most generic way of creating
> 
> debian packages will take precedence, since it comes with a generic
> workflow.
> 
> Otherwise we will have different solutions for different types of
> software packages.
> 
> 
> What I have implemented for know, was a generic debianization with:
> 
> 1. Generate the debian control file (fill with dependencies to other
> packages, built with Isar )
> 
> 2. Generate the debian "rules" makefile
> 
> 3. Run dh_make
> 
> 4. Run dpkg-buildpackage
> 
> It's a generic workflow and can be applied to any software package. It
> can also be turned off, if a software package already contains the
> required files within its debian folder.
> 
> 
> I will try to create patch series based on upstream Isar. For know its
> "only" a working solution within my Isar fork.
> 

But did you check dpkg-raw in upstream? It's not full debianization, but
at least packaging of pre-existing files with some degree of
customization. One should also be able to combine it with build steps
prior to running the packaging, though purists say that this is better
handled with real debian control files.

Of course, whenever we can generalize common tasks, just parameterizing
their details, that could be offered as class for reuse.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux