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

[Benedikt Niedermayr <benbrenson89@googlemail.com>]

Am 25.01.2018 um 19:36 schrieb Jan Kiszka:
> [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
>

> Well, this case is about the kernel itself, only. The control files
> needed to build the kernel are not reusable for other tasks.
I did not catch how kernel control file differs from other control files 
(apart from dependencies) ?

> 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.
That's a good and smart solution for the beginning I think.

Next step could be to generate Build-Depends and Depends for the control 
file?


Benni