From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-project+bounces-3961-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 8079713877A
for <garchives@archives.gentoo.org>; Sat, 2 Aug 2014 15:04:30 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C3338E0A82;
Sat, 2 Aug 2014 15:04:27 +0000 (UTC)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 138E9E0A52
for <gentoo-project@lists.gentoo.org>; Sat, 2 Aug 2014 15:04:26 +0000 (UTC)
Received: by mail-wi0-f173.google.com with SMTP id f8so2807963wiw.6
for <gentoo-project@lists.gentoo.org>; Sat, 02 Aug 2014 08:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20120113;
h=date:from:to:subject:message-id:in-reply-to:references:mime-version
:content-type;
bh=+oPO88rW2Fxo9Tou64qCK9NKqhmDL75nahXy2A9NYa4=;
b=wb7BGhYf/t5aiR23tqguq3oqXrDohH1EdZMdA/QpzNrgalq3n+U/EeDmyaYMTF+vBZ
12q9K/xfpRB2glqADf7kBTGefVtbDIbLPsgqeDYYA3T2sOJzZzG4VQsckl9hnJd2nibw
rk04rbRV9fIe8mC+VnTEZfG96Q7xANFF0ZCpx/o2iK8XKXmkN/7SvOotv7xHOKsB0fvv
uQ/YNMr59MsiNdwhjQeg5PmY/GolwAQtHWnjjhs1MyL4abZQgAiQDzaP25TjjyH7dw11
tpW7Z64hQ55Tq24KBcmlrt4aY65dwfboDDHD2W3Qxh3hmnCIKhxfGTnDSNcYcOnuPG//
Ahqg==
X-Received: by 10.180.20.40 with SMTP id k8mr17314923wie.38.1406991865657;
Sat, 02 Aug 2014 08:04:25 -0700 (PDT)
Received: from localhost (cpc2-broo7-2-0-cust637.14-2.cable.virginm.net. [86.11.186.126])
by mx.google.com with ESMTPSA id je3sm19979709wic.11.2014.08.02.08.04.25
for <gentoo-project@lists.gentoo.org>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 02 Aug 2014 08:04:25 -0700 (PDT)
Date: Sat, 2 Aug 2014 16:04:20 +0100
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting
2014-08-12
Message-ID: <20140802160420.20d10e31@googlemail.com>
In-Reply-To: <CAGfcS_k+QesiniwFESthQgU9=F2FG964QBJ0452k_UWJ1_mdcQ@mail.gmail.com>
References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de>
<lrdkgi$r38$1@ger.gmane.org>
<53DA69DA.8020000@gentoo.org>
<CAGfcS_m-NkqhQUbzHk+Q8vg=vn-YQJ_uwSuf_zL0c=t_H6FbTQ@mail.gmail.com>
<53DB7F42.4010609@gentoo.org>
<CAGfcS_mF+uamjq0YZwpxmcTQs2Ux5ThWnnQ1v8uG1rq5nt0RHA@mail.gmail.com>
<53DB901C.4090004@gentoo.org>
<CAGfcS_kJYrVaOjUEoJ5wDmm=Y+DE7opjhv7nP3QGPq9AUk9x6A@mail.gmail.com>
<20140801143741.1ebf8df6@googlemail.com>
<CAGfcS_k+QesiniwFESthQgU9=F2FG964QBJ0452k_UWJ1_mdcQ@mail.gmail.com>
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.24; x86_64-pc-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
boundary="Sig_/lTPw.7KgH7j/4IN+SgR+wu1"; protocol="application/pgp-signature"
X-Archives-Salt: 03387750-513a-4cef-af43-3666013594c5
X-Archives-Hash: 15f648c3ef7fb23bcbb1aab4f10f857e
--Sig_/lTPw.7KgH7j/4IN+SgR+wu1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Fri, 1 Aug 2014 10:00:34 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> The thing is, giving up things like @preserved-rebuild seems a bit
> like threatening to kill kittens until people wake up and clean their
> code. We're talking about ripping out 80% solutions in favor of 20%
> solutions in order to motivate ourselves to build 100% solutions.
preserved-rebuild isn't an 80% solution. It's a 90% problem.
> > * They suddenly stop working if an ebuild is removed.
>=20
> This is only the result of the current implementation, which begins
> taking into account dynamic dependencies but then doesn't update VDB.
> I think a better approach is that once a dynamic dependency is used,
> the VDB should be updated to reflect it.
This only fixes the special case where the change is "seen".
> That is my concern with this kind of approach. It results in a much
> cleaner data model, but it doesn't actually fix the reality that
> things break when they have wrong dependencies.
Things are already broken if developers are specifying wrong
dependencies. We have bigger problems if your assertion is that
developers getting dependencies wrong is so common that revbumping to
fix them would affect users.
> > * They don't work with binary packages.
> >
>=20
> Sort-of. This is really just the VDB updating problem again, though
> complicated by the fact that your binary package contains its own VDB.
> It might be fixable at time of merging it, and if the original ebuild
> isn't around at that time then you're back to the static dep model
> which either breaks or not in the same way it would have before.
Static dependencies only break if a developer screws up, which should
be rare. Dynamic dependencies break under normal operation.
> > * They're utterly incompatible with subslot deps.
>=20
> I get that they aren't implemented with subslot deps. I'm not quite
> sure why they can't be. When a new dep shows up, record the subslot
> used to satisfy it when it is first satisifed.
There's no simple mapping in the "complex mess of || dependencies" case.
> > * Someone adds selinux support to foo. Then a new bar starts
> > requiring foo[selinux]. The user hasn't rebuilt their foo to get
> > selinux support, but the dependency is still met, thanks to dynamic
> > dependencies.
>=20
> I don't see this as having anything to do with dynamic dependencies.
> If foo was built without selinux, then it wouldn't meet the
> dependency. USE changes can't be assumed as not impacting the
> installed files - I doubt this would be true in even a small minority
> of cases.
I included this one because it was presented as a "feature" of dynamic
dependencies earlier in the discussion.
> I'm not entirely sure if this is just an implementation issue.
It isn't. It's a design flaw.
--=20
Ciaran McCreesh
--Sig_/lTPw.7KgH7j/4IN+SgR+wu1
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlPc/fcACgkQ96zL6DUtXhEJ+wCeI+uIcAVsucoYJX4lOKhD616J
aHgAoI3FhvIFebAmiALQzCGXL23xEKAa
=gfZ0
-----END PGP SIGNATURE-----
--Sig_/lTPw.7KgH7j/4IN+SgR+wu1--