From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mail.openembedded.org (Postfix) with ESMTP id 486517017D for ; Thu, 24 Nov 2016 10:25:35 +0000 (UTC) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 24 Nov 2016 02:25:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,690,1473145200"; d="scan'208";a="790274030" Received: from marquiz.fi.intel.com ([10.237.72.155]) by FMSMGA003.fm.intel.com with ESMTP; 24 Nov 2016 02:25:35 -0800 Message-ID: <1479983134.13463.26.camel@linux.intel.com> From: Markus Lehtonen To: David Vincent , openembedded-core@lists.openembedded.org, haris.okanovic@ni.com Date: Thu, 24 Nov 2016 12:25:34 +0200 In-Reply-To: <20161124092636.9533-1-freesilicon@gmail.com> References: <20161124092636.9533-1-freesilicon@gmail.com> X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Subject: Re: [PATCH v3] classes: Fix alternatives and rc.d ordering X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 10:25:35 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2016-11-24 at 10:26 +0100, David Vincent wrote: > When using an alternative as an initscript, the ordering between > update-rc.d and update-alternatives tasks during prerm and postinst > tasks must always be the following in order to work: > * prerm: > - stop daemon > - remove alternative > > * postinst: > - add alternative > - start daemon > > This patchset adds comments to the scripts generated by both classes and > organize the generated sections based on those comments. > > [YOCTO #10433] I also commented this in the bug, but after playing with these a bit I'm not convinced that init scripts should be managed by update-alternatives. First, I don't see much reasoning why two syslog services should be installed in parallel. Also, no other package or distro use this kind of construction, AFAIK. So I'd avoid complication of the bbclasses for the purpose of one package only. If we really want to make these install in parallel I think we should just name the files differently. Thanks, Markus