public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Enrico Weigelt, metux IT consult" <info@metux.net>
Cc: 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 12:57:03 -0500	[thread overview]
Message-ID: <20190308175703.GA7178@lambda> (raw)
In-Reply-To: <1552049064-32044-1-git-send-email-info@metux.net>

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

  parent reply	other threads:[~2019-03-08 18:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08 12:44 Debian build polishing 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 ` Theodore Ts'o [this message]
2019-03-08 21:10   ` Debian build polishing Enrico Weigelt, metux IT consult
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=20190308175703.GA7178@lambda \
    --to=tytso@mit.edu \
    --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=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