From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:43220 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726997AbfGPMfA (ORCPT ); Tue, 16 Jul 2019 08:35:00 -0400 Date: Tue, 16 Jul 2019 08:34:31 -0400 From: "Theodore Y. Ts'o" Subject: Re: [PATCH 4/4] debian: add generic rule file Message-ID: <20190716123431.GB2999@mit.edu> References: <1562664759-16009-1-git-send-email-info@metux.net> <1562664759-16009-4-git-send-email-info@metux.net> <5af9db32-2cf5-10ba-261c-e08852d0814f@metux.net> <20190715191245.GD3068@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kbuild-owner@vger.kernel.org List-ID: To: Masahiro Yamada Cc: "Enrico Weigelt, metux IT consult" , "Enrico Weigelt, metux IT consult" , Linux Kernel Mailing List , Michal Marek , Robo Bot , Joe Perches , Linux Kbuild mailing list , linux-riscv@lists.infradead.org, clang-built-linux 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43BD5C76188 for ; Tue, 16 Jul 2019 12:34:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 19D6620880 for ; Tue, 16 Jul 2019 12:34:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HB+H2dsq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19D6620880 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=E50UojnAIcVoCouWbsQ9bzeyB/Na3eQGZ1Syn03LN1c=; b=HB+H2dsqK5XbM1 MHW8/V/3SGDJmQbMQIFFcKpNfNSGiW/LqMCoeMSIdPQusGqy9vT8DjiBzbvrUrWG0UywIGGgvPfft Vg7/dJzjXNk19669WW0V3qG3abJJIv/OqiTJ/kOZh2KjygvbjwIowhAXRePFU66Ck7WGy6v77u9XB NdG5tngZdUks8VBagVctikpJ9dqqCSiLCPItKiByBgAPkmoT1QNKbqP6Gg47tSlA+B18un/V0ir68 hmJeIxJlLR45pae760J1JalwEb9thUzSphfM+nRXtnazfrgQCvZdT4GGhl2Pq1WZTTLiOZ8Nden49 oHQoG+OFA6ko1es4CfDg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hnMfL-0004a8-LY; Tue, 16 Jul 2019 12:34:43 +0000 Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hnMfI-0004ZV-FT for linux-riscv@lists.infradead.org; Tue, 16 Jul 2019 12:34:42 +0000 Received: from callcc.thunk.org (guestnat-104-133-0-99.corp.google.com [104.133.0.99] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6GCYWYd026006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jul 2019 08:34:33 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id EBB74420054; Tue, 16 Jul 2019 08:34:31 -0400 (EDT) Date: Tue, 16 Jul 2019 08:34:31 -0400 From: "Theodore Y. Ts'o" To: Masahiro Yamada Subject: Re: [PATCH 4/4] debian: add generic rule file Message-ID: <20190716123431.GB2999@mit.edu> Mail-Followup-To: "Theodore Y. Ts'o" , Masahiro Yamada , "Enrico Weigelt, metux IT consult" , "Enrico Weigelt, metux IT consult" , Linux Kernel Mailing List , Michal Marek , Robo Bot , Joe Perches , Linux Kbuild mailing list , linux-riscv@lists.infradead.org, clang-built-linux References: <1562664759-16009-1-git-send-email-info@metux.net> <1562664759-16009-4-git-send-email-info@metux.net> <5af9db32-2cf5-10ba-261c-e08852d0814f@metux.net> <20190715191245.GD3068@mit.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190716_053440_687813_81A87598 X-CRM114-Status: GOOD ( 11.18 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michal Marek , Linux Kbuild mailing list , Linux Kernel Mailing List , Joe Perches , "Enrico Weigelt, metux IT consult" , clang-built-linux , Robo Bot , linux-riscv@lists.infradead.org, "Enrico Weigelt, metux IT consult" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org 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