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 111CE138262 for ; Tue, 17 May 2016 08:03:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 451481423F; Tue, 17 May 2016 08:02:54 +0000 (UTC) Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com [209.85.161.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 29EF214218 for ; Tue, 17 May 2016 08:02:53 +0000 (UTC) Received: by mail-yw0-f175.google.com with SMTP id g133so7956128ywb.2 for ; Tue, 17 May 2016 01:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=ihcG3SWwdasemyX0ROc6KB1ozSr65T3YE8CM+pjt2T4=; b=T4URXWpceNuI9gyBSB89KJ571wQkZFX7eWgr8EtcBUNT6DjcJMA089oW6yIrnrnacY yrbLMDiRx1QtHKrmbYiXXTf1QhwccZ5NVqKOWZ0TL39UP46lk3W0FMztd4wnrzlkZugf E/tq8WwMwAc4VA22omH+UIaZ283P30Bj+mUZkJPAua+UniL1pXuIQo1RWTM/qyYqVykp Vu/pRgNNxc1ak5+rownmoolenM+9RL3y3hkWdIj+6cQNn9lZGqfbteCW8UGBNqVbFQl7 0jP03/C2pp9pYNoSnfSrreIBbHUf0NShnsGgR6OJz7mpkcwTcqGO+9RgSkkF1Hcjnwc0 9HNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=ihcG3SWwdasemyX0ROc6KB1ozSr65T3YE8CM+pjt2T4=; b=Du82gQ24uCa2YeP4Bl10uQqkQwxtoQUa6/0a2yiYq1cnBJUM0pPUYgtesgyWCrQKo7 ZI6XmJYFEjggncP87fB5KouhBJrZEmYiZ+NdxrqdcQ5B1nglUtzEIgT3xrbbEmyYBLb8 xM+Uvndnr1L+TqslMQJ2jte2lUESXxc3QmgXpG336kGZy5v+iaKxRndk1Q8Z/C+n7XWv f3XaJd40gyCRGGiGP8OX/GWwbLrmALPnNimcKoyGB0WDaRPXPM05aOKtTdwRMGuRanx5 t3Hs7OBX1IEula2syIsl15CwASCJFClr+qag9BH/Z8G5QpiwDyq67SYw8vg8mqjvarJ8 gTLg== X-Gm-Message-State: AOPr4FVhu8YjaDPREelak1TCY9ucb3LVG5fvpkrtaOaNUE1DxZDJ6mhA8luVtBETf5JulOnOQSc5LWozJfJ+Kg== 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 X-Received: by 10.13.227.196 with SMTP id m187mr18360625ywe.18.1463472172426; Tue, 17 May 2016 01:02:52 -0700 (PDT) Received: by 10.13.241.199 with HTTP; Tue, 17 May 2016 01:02:52 -0700 (PDT) In-Reply-To: References: <20160516183840.4b241463@gentp.lnet> Date: Tue, 17 May 2016 20:02:52 +1200 Message-ID: Subject: Re: [gentoo-dev] Proposal for changes for the next EAPI version From: Kent Fredric To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 1125fb5e-d1ed-4f0b-84fd-531657fc7e53 X-Archives-Hash: 9c529e890a624bc1c56ff4411aca5ce2 On 17 May 2016 at 19:37, Pallav Agarwal wrote: > For normal users we wouldn't. But currently, arch-testers need to make a > judgement call on what to test when a stable-req bug is filed. Tests run in > src_test are provided by upstream, and does not guarantee that a package > that has been merged will actually run on the system. > If the maintainer could add a couple small scripts to check basic > functionality > of the merged package, it would make testing for arch testers much easier > and reliable. > Let me give an example. Let's say > app-misc/screenfetch-2.7.7 is the current stable package for screenfetch in > the portage tree. > However, on running, it produces an error on the top, along with the proper > output. > If screenfetch-3.0.0 happens to fix that error, maintainer can add a simple > script > > if [ "$(screenfetch 2>&1 1>/dev/null)" != "" ] then > eerror "Still producing error" > fi > > To make sure the build is properly updating the screenfetch version, and > that > the bug has in fact been fixed. This is the only way I can see to reliabily > and automatically test packages that have been merged successfully I don't think this needs to be an EAPI change. And if we can acheive the goal without one, the better. For instance, repoman is progressing in a way that repoman is becomming pluggable, and that will hopefully be more useful. Mostly, because it will allow us to define checks based on "inherit" lines, and based on project/maintainer values in metadata.xml, in theory. You *could* theoretically augment this on an ebuild-by-ebuild basis, but I would encourage doing as much as we can in this sphere outside that workflow, because it will burden ebuilds with unhelpful stuff, and it will increase commit churn on gentoo simply for QA reasons. But the reality is, you have to think not on ebuild-by-ebuild basis, you have to think how this scales in volume, both against large repositories of ebuilds, and how it scales in regards to 1-maintainer-thousands-of-ebuilds and 1-project-thousands-of-ebuilds and 1-eclass-thousands-of-ebuilds scales. For instance, there's very obvious applications for sets of gentoo defined quality tests in dev-perl/, but anything we devise is going to apply to all of them. _And_ to achieve our goal, we will likely need external dependencies satisfied. And I'd hate to be burdening those hundreds of ebuilds with that overhead, its much better implemented out-of-band first, and then only supplemented on an ebuild-by-ebuild basis. And under this scheme, individual projects can define their custom hooks and tricks in the ebuild themselves as metadata ( like we currently to via eclass variables ), and be handled, not by portage, or PMS, not by EAPI, but by the QA tool in conjunction with eclass designers. Then, no need for formal EAPI is required. The QA tool just sources the ebuild in bash, hands the metadata to the plugin, and the plugin can then execute whatever functions it wanted. And the other benefit of doing this outside EAPI: It doesn't have to be part of PMS, and maintainers of other packaging tools are not compelled to implement a feature that is not relevant to end users. And this also means our velocity with regards to changing what we do here is much quicker, as we're no longer bound by the tight QA controls we have to make sure we don't break users systems, because we are *only* targeting devs. -- Kent KENTNL - https://metacpan.org/author/KENTNL