Re: Debian build polishing
(+CC more debian folks) On Fri, Mar 8, 2019 at 9:45 PM Enrico Weigelt, metux IT consult wrote: > > Hi folks, > > > here're some patches for polishing up the Debian packaging stuff, > so it can be directly used w/ usual Debian machinery like > pbuilder, git-buildpackage, dck-buildpackage, etc. > > These expect debian/rules to exist in the unpacked/patched tree > and drive the whole build. Currently 'make deb-pkg' does it in > the opposite direction - it creates debian/rules and fills in > some data, that's derived from .config etc. > > My goal is building the kernel package in exactly the same way as > any other Debian package - so there must be a debian/rules as the > primary entry point. To do that, w/ minimal change and w/o breaking > the existing machinery, I'm going in several steps: > > #1: add Makefile rules for retrieving missing makefile-internal > variables kernel config system .config (eg. kernel arch). > > this could be used for other build systems, too. > just call: `make kernelarch` or `make kernellocalversion` > > #2: add an env variable for changing the name of the rules file > generated by mkdebian. When coming from an existing rules > file, we can prevent this from being overwritten. > > #3: add a generic debian/rules file, that calls mkdebian to > create the remaining debian control files (w/ rules redirected > into nirvana) > > The existing `make deb-pkg` is bypassed and remains ontouched. > > One point still puzzling me: once the debian/rules is applied and > somebody calls `make deb-pkg`, he'll end up w/ unclean tree, as > now a git-tracked file is changed. Then, setlocalversion will set -dirty flag. Committing debian/rules looks questionable to me. > Perhaps I just change deb-pkg to call debian/rules then, but I'd > like to hear your oppinions about this, before. > > > What do you think about that ? > > > --mtx > > -- Best Regards Masahiro Yamada
Re: Debian build polishing
On 08.03.19 22:57, Theodore Ts'o wrote: > The full debian directory lands in the O= directory. So presumably > you could make it work for use case if there was a "make O=/build/dir > debian-prepare" which copies the necessary debian/ files into the > build directory and then someone could cd into /build/dir and run > "dpkg-buildpackage"? Didn't touch these rules at all, so it should still work as it used to. I thought about changing the old deb rules to just call the new debian/rules file, but haven't done so yet. Maybe you could find some time to test whether my approach also works for you ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Debian build polishing
On Fri, Mar 08, 2019 at 10:10:19PM +0100, Enrico Weigelt, metux IT consult wrote: > > So I really hope your patches don't break this. > > It shouldn't (at least I dont intend to). Haven't tried where exactly > the generated debian/rules file lands in your case. The full debian directory lands in the O= directory. So presumably you could make it work for use case if there was a "make O=/build/dir debian-prepare" which copies the necessary debian/ files into the build directory and then someone could cd into /build/dir and run "dpkg-buildpackage"? - Ted
Re: Debian build polishing
On 08.03.19 18:57, Theodore Ts'o wrote: > On Fri, Mar 08, 2019 at 01:44:19PM +0100, Enrico Weigelt, metux IT consult > wrote: >> One point still puzzling me: once the debian/rules is applied and >> somebody calls `make deb-pkg`, he'll end up w/ unclean tree, as >> now a git-tracked file is changed. > > This is not something I've noticed, but I build my Debian packages > like this: > > make O=/build/linux-build bindeb-pkg This doesn't work for my environment: The requirement is that every debian source tree has a ./debian/rules file (w/ the standard rules like binary, clean, ...). This is called by upper level build machinery (git-buildpackage, dpkg-buildpackage, ...) The idea behind is building all packages exactly the same way - one standard workflow, that just takes a source tree (from git) and spits out some .deb files. > So I really hope your patches don't break this. It shouldn't (at least I dont intend to). Haven't tried where exactly the generated debian/rules file lands in your case. > Also, are there any changes the performance of building the Debian > packages before and after your changes? And are there any differences > in the packages in terms of any pre-or-post install/removal scripts? I don't think so. In essence I just replace the generated rules file by a fixed one. Okay, it will take *a little* bit longer, as the rules file now calls `make kernelarch`, `make kernelrelease` and `make kernellocalversion`, before starting actual build. But that shouldn't be the big deal, IMHO. > There are a lot of things I really dislike about the "official" Debian > kernel build processes (they're optimzied for distribution release > engineers, not kernel developers), I try to bring these two world a bit closer together. > so I'm really hoping that making > things more like the "official Debian way" doesn't break some of the > things I really like about the existing "make bindeb-pkg" build > system. I intend not to. Actually, the official Debian way for Kernel build is entirely different, and that's really complicated and hard to really understand (that's why I'm doing this here). But here I'm just coping w/ the first entry point into the build process, which now becomes `./debian/rules binary` instead of `make bindeb-pkg`. The final result (in the .deb files) should be the time (unless I did something wrong). --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Debian build polishing
On Fri, Mar 08, 2019 at 01:44:19PM +0100, Enrico Weigelt, metux IT consult wrote: > One point still puzzling me: once the debian/rules is applied and > somebody calls `make deb-pkg`, he'll end up w/ unclean tree, as > now a git-tracked file is changed. This is not something I've noticed, but I build my Debian packages like this: make O=/build/linux-build bindeb-pkg This works really well for me, since all of the build-artificats land in /build, and I can use a HDD (or a PD-HDD when building using Google Compute Engine) for /build, while I use a SSD for my source tree. I find that using a HDD for a target of a build doesn't really slow things down, and this allows me to save $$$ (when using a Cloud VM) and reduce flash wearout and capital cost (on my personal machines). So I really hope your patches don't break this. Also, are there any changes the performance of building the Debian packages before and after your changes? And are there any differences in the packages in terms of any pre-or-post install/removal scripts? There are a lot of things I really dislike about the "official" Debian kernel build processes (they're optimzied for distribution release engineers, not kernel developers), so I'm really hoping that making things more like the "official Debian way" doesn't break some of the things I really like about the existing "make bindeb-pkg" build system. Cheers, - Ted
Debian build polishing
Hi folks, here're some patches for polishing up the Debian packaging stuff, so it can be directly used w/ usual Debian machinery like pbuilder, git-buildpackage, dck-buildpackage, etc. These expect debian/rules to exist in the unpacked/patched tree and drive the whole build. Currently 'make deb-pkg' does it in the opposite direction - it creates debian/rules and fills in some data, that's derived from .config etc. My goal is building the kernel package in exactly the same way as any other Debian package - so there must be a debian/rules as the primary entry point. To do that, w/ minimal change and w/o breaking the existing machinery, I'm going in several steps: #1: add Makefile rules for retrieving missing makefile-internal variables kernel config system .config (eg. kernel arch). this could be used for other build systems, too. just call: `make kernelarch` or `make kernellocalversion` #2: add an env variable for changing the name of the rules file generated by mkdebian. When coming from an existing rules file, we can prevent this from being overwritten. #3: add a generic debian/rules file, that calls mkdebian to create the remaining debian control files (w/ rules redirected into nirvana) The existing `make deb-pkg` is bypassed and remains ontouched. One point still puzzling me: once the debian/rules is applied and somebody calls `make deb-pkg`, he'll end up w/ unclean tree, as now a git-tracked file is changed. Perhaps I just change deb-pkg to call debian/rules then, but I'd like to hear your oppinions about this, before. What do you think about that ? --mtx
