mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Theodore Ts'o <tytso@mit.edu>,
	"Enrico Weigelt, metux IT consult" <info@metux.net>,
	linux-kernel@vger.kernel.org, yamada.masahiro@socionext.com,
	michal.lkml@markovi.net, apw@canonical.com, joe@perches.com,
	linux-kbuild@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: Debian build polishing
Date: Fri, 8 Mar 2019 22:10:19 +0100	[thread overview]
Message-ID: <fe53cd84-5953-786a-3a4f-6eac652a1cdd@metux.net> (raw)
In-Reply-To: <20190308175703.GA7178@lambda>

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
info@metux.net -- +49-151-27565287

  reply	other threads:[~2019-03-08 21:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08 12:44 Enrico Weigelt, metux IT consult
2019-03-08 12:44 ` [PATCH v1 1/5] Makefile: rules for printing kernel architecture and localversion Enrico Weigelt, metux IT consult
2019-03-08 12:44 ` [PATCH v1 2/5] scripts: mkdebian: allow renaming generated debian/rules via env Enrico Weigelt, metux IT consult
2019-03-08 12:44 ` [PATCH v1 3/5] scripts: mkdebian: fix missing dependencies Enrico Weigelt, metux IT consult
2019-03-08 12:44 ` [PATCH v1 4/5] scripts: checkpatch.pl: don't complain that debian/rules is executable Enrico Weigelt, metux IT consult
2019-03-08 14:13   ` Joe Perches
2019-03-08 12:44 ` [PATCH v1 5/5] debian: add generic rule file Enrico Weigelt, metux IT consult
2019-03-08 17:57 ` Debian build polishing Theodore Ts'o
2019-03-08 21:10   ` Enrico Weigelt, metux IT consult [this message]
2019-03-08 21:57     ` Theodore Ts'o
2019-03-10 18:50       ` Enrico Weigelt, metux IT consult
2019-03-11 16:19 ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fe53cd84-5953-786a-3a4f-6eac652a1cdd@metux.net \
    --to=lkml@metux.net \
    --cc=apw@canonical.com \
    --cc=info@metux.net \
    --cc=joe@perches.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=michal.lkml@markovi.net \
    --cc=tytso@mit.edu \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®