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 F05A6138713 for ; Fri, 1 Nov 2013 00:45:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7FF70E09BF; Fri, 1 Nov 2013 00:45:23 +0000 (UTC) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 388ACE09B0; Fri, 1 Nov 2013 00:45:22 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id hu8so2545921vcb.28 for ; Thu, 31 Oct 2013 17:45:21 -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 :cc:content-type; bh=Ua74gOXJkts4H2rr9vvUkzA/xA1HFv5X8YK5K/+KQ5c=; b=SgbEKi2j8NK/3IzpvVYkWVXQ0eZLqnwCKETHTCxjQMOmEVkPpBHGTVQY8CBJa8R7fs lo+UbpWZiK10YgJDXU8gtpaefwSDgB1v5gG7Xy193kSefrV98bvoY7sJpEZOVHMnEmed fRXT77cKt0vih95T2fY4WO0DTLmlUXdzA8VOpAlesYrpRp6qer/7aJHVru7lePkXTd6T M8r/74h9Bas4Wxfxluz97VlgP5qPXzZP7jkfJqSmQfxq3BacQyv9BhaWZdu5wxgaEi7k /5OFQzSGsSmU9PHtAsmFGQW4Y1pivq8DYWI1dMTVf/qYLYOpkYjVJAmwA24YBS9zZXlX RuaQ== 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.58.207.15 with SMTP id ls15mr202786vec.17.1383266721314; Thu, 31 Oct 2013 17:45:21 -0700 (PDT) Received: by 10.58.7.10 with HTTP; Thu, 31 Oct 2013 17:45:21 -0700 (PDT) In-Reply-To: <20131031230212.1ea303a9@egeo.atlantide.net> References: <20131031230212.1ea303a9@egeo.atlantide.net> Date: Fri, 1 Nov 2013 13:45:21 +1300 Message-ID: Subject: Re: [gentoo-dev] vim and gvim package split From: Kent Fredric To: gentoo-dev@lists.gentoo.org Cc: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=047d7b6dc6ee8dc49a04ea12e13d X-Archives-Salt: ea07375b-8bef-4782-bd71-28a00051cac8 X-Archives-Hash: 797ad22db61dfbae682b0a5b2d4f4b36 --047d7b6dc6ee8dc49a04ea12e13d Content-Type: text/plain; charset=UTF-8 On 1 November 2013 11:02, Alessandro DE LAURENZIS wrote: > > In case of vim-core/vim/gvim (and vim-qt?), I cannot understand > the reason... Are still there advantages in doing so? Useflags have their perks for giving variations on behaviour, but having 3 effective packages in one, governed by useflags, means you'll have 3 much more tightly coupled packages, and the code will be much messier with useflag conditionals to pull dependencies. If you imagine useflags like "if" statements, and ebuilds like independent classes where "dependencies" are a kind of inheritance, you may find theres' reasonable benefits for the maintenance side e.g.: people checking reverse deps for QT don't have to worry about changes in QT breaking vim and gvim because those packages are independent of QT interaction Fixes that need to go in to make building vs QT mean only the qvim ebuild gets updated and the rest are fine as-is. The only real downside is if you're building all 3 {q,g,}vim there's a little compile time overhead as a result ( Though I'm not sure what the difference is in real terms ) But by having them seperate, we enjoy a more robust installation, especially for people who only want one of the 3, then they're not needlessly burdened by logic to handle things they're not using, which could break. Not to mention you have to deal with overheads introduced by having to work out the equivalent of all three of the above having vastly different useflags and making useflags conditional upon each other as a result to codify the same behaviour, again, further raising the odds that a situtation will arise where things break and the dependencies/use flags are a mess. -- Kent --047d7b6dc6ee8dc49a04ea12e13d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 1 November 2013 11:02, Alessandro DE LAURENZIS <just22.adl@gmail.com= > wrote:

In case of vim-core/vim/gvim (and vim-qt?), I cannot understand
the reason... Are still there advantages in doing so?
Useflags have their perks for giving vari= ations on behaviour, but having 3 effective packages in one, governed by us= eflags, means you'll have 3 much more tightly coupled packages, and the= code will be much messier with useflag conditionals to pull dependencies.<= br>
If you imagine useflags like "if&= quot; statements, and ebuilds like independent classes where "dependen= cies" are a kind of inheritance, you may find theres' reasonable b= enefits for the maintenance side

e.g.: people checking reverse deps for QT don't have to worry abou= t changes in QT breaking vim and gvim because those packages are independen= t of QT interaction

Fixes that need to go in to make building = vs QT mean only the qvim ebuild gets updated and the rest are fine as-is.
The only real downside is if you'= ;re building all 3 {q,g,}vim there's a little compile time overhead as = a result ( Though I'm not sure what the difference is in real terms )
But by having them seperate, we enjoy = a more robust installation, especially for people who only want one of the = 3, then they're not needlessly burdened by logic to handle things they&= #39;re not using, which could break.

Not to mention you have to deal with o= verheads introduced by having to work out the equivalent of all three of th= e above having vastly different useflags and making useflags conditional up= on each other as a result to codify the same behaviour, again, further rais= ing the odds that a situtation will arise where things break and the depend= encies/use flags are=C2=A0 a mess.

-- Kent
--047d7b6dc6ee8dc49a04ea12e13d--