From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SPBuZ-0001ov-FM for garchives@archives.gentoo.org; Tue, 01 May 2012 12:10:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 28FCDE0782; Tue, 1 May 2012 12:10:21 +0000 (UTC) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.180]) by pigeon.gentoo.org (Postfix) with ESMTP id BA983E0782 for ; Tue, 1 May 2012 12:10:20 +0000 (UTC) X-RZG-AUTH: :IW0NeWCpcPchHrcnS4ebzBgQnKHTmUiSF2JlOcyz+57jTVMtVX7471ELeN8= X-RZG-CLASS-ID: mo05 Received: from pinacolada.localnet (95-130-166-116.hsi.glasfaser-ostbayern.de [95.130.166.116]) by smtp.strato.de (jorabe mo38) (RZmta 28.16 AUTH) with ESMTPA id j0644eo416BUui for ; Tue, 1 May 2012 14:10:19 +0200 (CEST) From: "Andreas K. Huettel" To: gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] Re: EAPI 5 Date: Tue, 1 May 2012 14:10:37 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.1-gentoo; KDE/4.8.2; x86_64; ; ) References: <20120415021641.1858ffde@gentoo.org> <201205011101.57611.dilfridge@gentoo.org> <20120501101625.2172aeb8@googlemail.com> In-Reply-To: <20120501101625.2172aeb8@googlemail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Reply-To: gentoo-pms@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205011410.37811.dilfridge@gentoo.org> X-Archives-Salt: e235de23-a09b-4496-8763-186e52ec1880 X-Archives-Hash: 05625a25a985597f446cc98dea87020e Am Dienstag 01 Mai 2012, 11:16:25 schrieb Ciaran McCreesh: > On Tue, 1 May 2012 11:01:57 +0200 > > "Andreas K. Huettel" wrote: > > Am Dienstag 01 Mai 2012, 10:38:41 schrieb Ciaran McCreesh: > > > > Well. PMS describes the files in a profile directory. If > > > > * we introduce a new file via PMS that was not in there before, > > > > * and another package manager accesses that file but expects > > > > different information there not corresponding to our new > > > > definition, that package manager should be considered broken > > > > because it is not adhering to previous PMS revisions. So? > > > > > > What happens if a user uses an EAPI 4 ebuild with an EAPI 4 package > > > manager when the ebuild in question would be hit by your new files, > > > which the package manager doesn't know about yet? > > > > Err, nothing? The useflags remain available and switchable as before, > > no difference regarding useflags between stable / not stable? > > What is the impact of this, then? Does it mean users will start to see > lots of "masked" errors that they should not be seeing? If * the ebuild is <= EAPI 4 * the ebuild is listed in package.stable.use.(mask|force) then it will be possible to enable/disable features in the stable variant that are not really deemed suitable for a "stable package" yet. All quality requirements from ~arch remain, meaning also the use flag combinations should lead to a successful build and a reasonably working package. Also, the stable ebuild will then eventually depend on non-stable packages, which is bad. Thus, I would strongly recommend that this situation is treated as a blocker for stabilization (either upgrade EAPI or modify the package.stable.use.(mask| force) entry so it does not apply to this ebuild). Repoman could prevent such a commit. It might make sense to go even further and write explicitly that package.stable.use.(mask|force) entries must not resolve to any <= EAPI 4 ebuilds. Unfortunately there is no automatic repoman check during commits in the profile dirs which could prevent it. -- Andreas K. Huettel Gentoo Linux developer dilfridge@gentoo.org http://www.akhuettel.de/