On 15.07.19 21:12, Theodore Y. Ts'o wrote: Hi, > It's possible I'm not remembering some of the feedback, but the only> thing I recall was the comment I made that I'd really like this use> case:> > make O=/build/linux-build bindeb-pkg ah, I yet wanted to test that - thx for reminding me. > to not break. And as far as I can tell from the proposed patch series> (I haven't had a chance to experimentally verify it yet), I don't> think it should break anything --- I'm assuming that we will still> have a way of creating the debian/rules file in> /build/linux-build/debian/rules when doing a O= build, and that the> intdeb-pkg rule remains the same. At least, it appears to be the case> from my doing a quick look at the patches. Yes (unless i've missed something), everything should remain as it is. One thing that could happen (not checked yet) is that running good old 'make bindeb-pkg' without O=... could overwrite the now already existing debian/rules file. If that's really a problem, we could tweak the machinery to use a different name for the rule file (for now, one the preceeding patch just allows giving a different name for just *generating* the rules file). Another idea could be rewriting the whole process so that no rules file needs to be generated at all. > Yeah, the official Debian debian/rules is optimized for doing a > distribution release, and in addition to the issues Enrico has raised, > last time I tried it, it was S-L-O-W since it was building a fully > generic kernel. It's not at all useable for general developer use. I'm a bit reluctant calling this 'optimized' :p The strangest aspect (IMHO) is they're building several different trees (w/ different huge patch queues) from only one source package. Instead I'd rather: * try to get as much as possible in one tree * have separate source packages if there really need to be separate patche queues (IMHO, these things, like RT stuff, just need proper Kconfig's) * do all the patching in git and skip the text-based patches entirely Haven't found out, why they're actually doing it that complicated way (didn't get any useful answers from debian kernel folks) > It sounds like what Enrico is trying to do is to enable running > "dpkg-buildpackage -us -uc -b" from the the top-level kernel package > as being easier than running "make bindeb-pkg". I suspect this might > be because his goal is to integrate individual kernel builds from > using Debian's hermetic build / chroot systems (e.g., sbuild, pbuilder)? Yes, I'm building all deb's by the same process / infrastructure. In my case it's dck-buildpackage (*1) which runs the build in a docker container (kinda pbuilder w/ docker). It always starts with a fresh (minimal) base image, calls debian/rules to create debian/control (if necessary) deploys the dependencies found in the control file and finally fire's up dpkg-buildpackage - the output is collected in an ready-to-use apt repo. The goal of this is having a canonical build process for all deb packages, not having to care of any special cases anymore. I also have another tool ontop of that, which runs the whole show for dozens of packages and targets (*2). My first approach was trying to use Debian source packages with new kernel trees, but had to give up after a few days. Then I've found out that the kernel already has *almost* what I needed. The difference between almost and fine is this patch queue (minus local .config files) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
