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 1R1J8U-0006d3-Nc for garchives@archives.gentoo.org; Wed, 07 Sep 2011 14:29:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 84AC921C0E7; Wed, 7 Sep 2011 14:29:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C19F921C021 for ; Wed, 7 Sep 2011 14:29:12 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: scarabeus) by smtp.gentoo.org (Postfix) with ESMTPSA id 11B9F1B400D for ; Wed, 7 Sep 2011 14:29:11 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so345075bkb.40 for ; Wed, 07 Sep 2011 07:29:08 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.132.88 with SMTP id a24mr1440527bkt.47.1315405621345; Wed, 07 Sep 2011 07:27:01 -0700 (PDT) Received: by 10.204.180.9 with HTTP; Wed, 7 Sep 2011 07:27:01 -0700 (PDT) In-Reply-To: <20071.28643.758959.906951@a1i15.kph.uni-mainz.de> References: <4E64C7BB.907@gentoo.org> <20071.28643.758959.906951@a1i15.kph.uni-mainz.de> Date: Wed, 7 Sep 2011 16:27:01 +0200 Message-ID: Subject: Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting From: =?UTF-8?B?VG9tw6HFoSBDaHbDoXRhbA==?= To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 735d2e04dc04d419ec1d0e69b0466f1b 2011/9/7 Ulrich Mueller : >>>>>> On Wed, 7 Sep 2011, Tom=C3=A1=C5=A1 Chv=C3=A1tal wrote: > >> Start collecting ideas for EAPI5. > > I suggest that EAPI 5 should include the two features that have been > omitted from EAPI 4 [1,2]. > > Apart from this, I think we should be more careful for the next EAPI, > in order to avoid such long delays as we had with EAPI 4. One possible > solution would be to only accept features where a preliminary > implementation in Portage is available. Agreed the wait last time was really bad. > >> I myself would like PATCHES array to be default in src_prepare phase >> and some solution for runtime optional deps, Instead of elog in >> postinst something like Recommended from rpm. > > Looks reasonable (if an implementation is ready). Although I don't > understand how it is related to rpm. Well the patches code is in base eclass. For Recommended it works like this: blabla.spec Recommended: xf86-video-ati zypper in blabla ... You might consider installing these additional packages: xf86-video-ati It for sure needs more thinking as this is just basic idea. It might even take into account that if you install the recommended patckage with oneshot it should not be depcleaned unless all recommending packages are gone too, and so on.