From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 69B021391DB for ; Fri, 1 Aug 2014 12:44:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CC23FE0999; Fri, 1 Aug 2014 12:44:26 +0000 (UTC) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3E22AE097C for ; Fri, 1 Aug 2014 12:44:26 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id hy4so6500198vcb.41 for ; Fri, 01 Aug 2014 05:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=wDDZ+R9Q1KntZQH8/7SV1ihFvst46ZVPoLoVk4z2P3Q=; b=yM6Dn+1iu5OwjZi3LhZ9yYMdGt3Wqmy1Gg+9AcOM6d7Iz0IxORb7auYkaNLRlc0Mls 9qz1Mgfu5Dlii/dxh0E3sclGKO9KyRNtbQshayizNZYHQWP//t7jShHbYpryJb9tV1cL uiePTUsjSz/JRdjeLxi/fIx3Vlz5UJXcWL438GOjrq6/ukkMisgkRNJX82pD9uJHHMec Le1fef9Bt9uWqoooWeij0+qpLjCvYtwSumiMEAxtoTwGLch9KS3dhDk5CQzsQyr4P5cu VDauZcgO9yp3cItQhMuIOpUOKfOSvRSCjETKw6mY8Py8ZeX9MuekRE7cNh3CZQJQVFUU sR9Q== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.81.129 with SMTP id a1mr1725007vdy.80.1406897065387; Fri, 01 Aug 2014 05:44:25 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Fri, 1 Aug 2014 05:44:25 -0700 (PDT) In-Reply-To: <53DB7F42.4010609@gentoo.org> References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> <53DA69DA.8020000@gentoo.org> <53DB7F42.4010609@gentoo.org> Date: Fri, 1 Aug 2014 08:44:25 -0400 X-Google-Sender-Auth: N3XAm2fO_mxNTbnNJiZxXb2Hdto Message-ID: Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f31b729c-7987-4313-9af9-9a029c9bbbca X-Archives-Hash: 633990c0b0e698e93b066cf0d3a9db74 On Fri, Aug 1, 2014 at 7:51 AM, Alexander Berntsen wr= ote: > On 01/08/14 02:34, Rich Freeman wrote: >> So, this is more than just a portage design question, and I think >> it is fair for the Council to take up. Obviously the feelings of >> the portage maintainers should be carefully considered. > Dynamic dependencies are not specified. None of this stuff is specified, dynamic or static. The only thing in PMS is how to declare a dependency. It says nothing about how a package manager should rely on this. As was pointed out, portage prerm is broken with both dynamic and static deps (and in my last email I limited this to slot operator deps, but in reality it is broken anytime it depends on linkage whether the slot operator dep is expressed or not). I don't think that is a huge issue in practice, but I've yet to hear an example of anything which is. > As such, this is in fact a bug > rather than a question of design. So, at work I have the luxury of systems that have broken requirements instead of just broken implementations, but for as good as PMS is it falls very short of being a full functional requirement specification for portage. The lack of a specified function in PMS does not mean that implementing this in portage is a bug. > > Personally, I am slightly surprised by the reactions and uproar this bug > fix has caused. At my day job, we commend each other for fixing bugs, > and express gratefulness for the effort. The problem is that not all agree that dynamic dependencies are a bug. It isn't obvious that static deps are specified behavior, and even if it were specifications can be changed before software is released when there is agreement that they're incorrect. I am certainly grateful to the few that are continuing to contribute to portage development, however! Also, I apologize if this email comes across as antagonistic. I'm a bit on the fence regarding dynamic deps and mostly for practical reasons. I've yet to be convinced that they aren't workable (and this may simply be because I haven't noticed the argument against them). On the other hand, Micha=C5=82's post has gone a long way towards convincing me that removing them isn't that big of a deal, which leaves open the option of taking them out for now and then trying to come up with a cleaner implementation later. > > PMS does not specify dynamic dependencies. This means that if Portage > uses dynamic dependencies, and tree hackers rely on this behaviour, we > are needlessly making life difficult for users of other package > managers. Consequently, Portage should strive to follow the PMS's > intention as closely as possible. If you want to do some work on > formulating how dependencies are handled, please use the gentoo-pms > mailing list. I haven't spotted anything in PMS that specifies or necessitates static dependencies (citations are welcome). The content of VDB is not within PMS's scope, and that is where most of the impact of dynamic dependencies resides. > > Tree policy, I'm afraid, has to adapt to Portage; not the other way > around. The reality is that both portage and the tree policy need to adapt to the needs of the community, otherwise there won't be anybody around maintaining either. Nobody can change that - Portage team, PMS team, or even the Council. That is why we're better off focusing on communicating the need for change and understanding its impact, and not arguing about who gets to make the call. It also isn't enough to just tell people what they have to do to comply - they need to be convinced that they're doing it for a reasonably good reason, or at least that it was a debatable decision and the Council had to make a call one way or the other. I think that Micha=C5=82 has already taken some steps to make the impact of changing more clear. If we can just get a quick argument as to the need for change I think that would be helpful. It need not be exhaustive - if there are 500 things that break with dynamic deps a top 5-10 list should be more than sufficient. Rich