linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Joe Perches <joe@perches.com>,
	"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Robo Bot <apw@canonical.com>,
	linux-riscv@lists.infradead.org, "Enrico Weigelt,
	metux IT consult" <info@metux.net>
Subject: Re: [PATCH 4/4] debian: add generic rule file
Date: Tue, 16 Jul 2019 08:34:31 -0400	[thread overview]
Message-ID: <20190716123431.GB2999@mit.edu> (raw)
In-Reply-To: <CAK7LNASps6JBAvtJshjMbqMk8QaSrMaH8pm-wHsEySTRJzu0Kw@mail.gmail.com>

On Tue, Jul 16, 2019 at 05:58:49PM +0900, Masahiro Yamada wrote:
> I want debian/ to be kept as a drop-in directory
> for packagers, without replacing the upstream debian/rules.
> 
> If a check-in source file is modified in anyway,
> scripts/setlocalversion would set -dirty flag,
> which I want to avoid.

In practice, that's not going to be a problem for most distributions.
The traditional way Debian-derived systems have done builds is
completely outside of git.  So there will be a linux_5.2.orig.tar.gz
and a linux_5.2-1.debian.tar.xz.  dpkg_source -x will first unpackage
the orig.tar.gz, and then the debian.tar.xz, and if the second
overwrites the first, it's no big deal.

More modern Debian package maintainer workflows may be using git, but
in that case, all of the "Debianizations" are reflected in a separate
branch.  So it's not going to set the -dirty flag.

There will be potential merge conflicts between Enrico's proposed
"upstream default debian/rules" file and the Debian/Ubuntu
debian/rules file on their distro branch.  However, I don't think
that's a big issue, for two reasons.

First, once it's checked in, I expect changes to the default
debian/rules file will be relatively rare.  Secondly, it's easy enough
to use gitattributes and defining a custom merge driver so that a
distribution can configure things so that they always use the version
of debian/rules from their branch, so the merge conflict resolution
can be set up to always do the right thing.

There are certainly other upstreams which ship their own debian/
directories.  E2fsprogs is one such example, but in that case I'm
cheating because I'm both the Debian package maintainer as well as the
upstream maintainer.  :-)   However, it's never been an issue for Ubuntu
when they choose to ship their own customized debian/rules file.

> debian/rules is a hook for packagers to do their jobs in downstream.
> "We kindly committed a generic one for you" sounds weird to me.

It is weird, and it's not common for upstream packages (which are not
native Debian packages) to ship their own debian directory.  But it
certainly does happen, and it won't cause any problems in actual
practice.

Regards,

					- Ted

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-07-16 12:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09  9:32 [PATCH 1/4] Makefile: rules for printing kernel architecture and localversion Enrico Weigelt, metux IT consult
2019-07-09  9:32 ` [PATCH 2/4] scripts: mkdebian: allow renaming generated debian/rules via env Enrico Weigelt, metux IT consult
2019-07-09  9:32 ` [PATCH 3/4] scripts: checkpatch.pl: don't complain that debian/rules is executable Enrico Weigelt, metux IT consult
2019-07-09 10:16   ` Joe Perches
2019-07-09  9:32 ` [PATCH 4/4] debian: add generic rule file Enrico Weigelt, metux IT consult
2019-07-15 12:28   ` Masahiro Yamada
2019-07-15 18:56     ` Enrico Weigelt, metux IT consult
2019-07-15 19:12       ` Theodore Y. Ts'o
2019-07-16  8:58         ` Masahiro Yamada
2019-07-16 12:34           ` Theodore Y. Ts'o [this message]
2019-07-17 14:16             ` Enrico Weigelt, metux IT consult
2019-07-17 15:23               ` Theodore Y. Ts'o
2019-07-17 11:08         ` Enrico Weigelt, metux IT consult
2019-07-09 14:54 ` [PATCH 1/4] Makefile: rules for printing kernel architecture and localversion Randy Dunlap

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=20190716123431.GB2999@mit.edu \
    --to=tytso@mit.edu \
    --cc=apw@canonical.com \
    --cc=clang-built-linux@googlegroups.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=lkml@metux.net \
    --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;
as well as URLs for NNTP newsgroup(s).