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 689A91381F3 for ; Sun, 16 Jun 2013 10:53:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 22156E096B; Sun, 16 Jun 2013 10:53:09 +0000 (UTC) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6603BE0961 for ; Sun, 16 Jun 2013 10:53:08 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id pb11so1461669veb.9 for ; Sun, 16 Jun 2013 03:53:07 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=FqgmIhGAMnh3BAPIW7RZ8V6ICmRmqWn+3YvxEHCmJKA=; b=uZvVxxJTd9VavDm6elhcypJ0TSZBPH78mZwU911LcFDkhlE9epA2wIV/P4RzFejGoz AoQndqLYOaSJrnrN4nlxfRbRDZV+KXiL4E9PjGUgS53OmarmSHDkmwzsRNLQXF6wtpVw N4ai3KW35dbv7mxfx/UKNWrvs4otw4QVLBtyyS/J1+58pzrfGtDZuxhT0b7ckjzTgs5j BByg7ss8GdvkPX27hrnx2+C5C6uUNrP1DCNnwN22GkdGJ59WHdweLGg2JEBr/zv3xCY6 0JBMgu3GYLd6THXMJtOR3pczi4jSgx6mt+6/kVEz2YtsZktYnn4IMjbzWRemd947n1aT myFg== 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.58.69.65 with SMTP id c1mr2115317veu.88.1371379987402; Sun, 16 Jun 2013 03:53:07 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.73.3 with HTTP; Sun, 16 Jun 2013 03:53:07 -0700 (PDT) In-Reply-To: <20130616122154.47c8a591@TOMWIJ-GENTOO> References: <20130616093322.GB20905@waltdnes.org> <20130616122154.47c8a591@TOMWIJ-GENTOO> Date: Sun, 16 Jun 2013 06:53:07 -0400 X-Google-Sender-Auth: q4XiWGAr_ud5oZwJ0LrIWKCeh1I Message-ID: Subject: Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update)) From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 097045ff-7ace-4c35-b057-e6984195098b X-Archives-Hash: 18a35e2bfbd06ee082064d28e134be1d On Sun, Jun 16, 2013 at 6:21 AM, Tom Wijsman wrote: > On Sun, 16 Jun 2013 05:33:22 -0400 > "Walter Dnes" wrote: > >> I think the best way to avoid maintainer conflicts is to take this >> out of the hands of maintainers, > > +1 I was planning to write a GLEP for a concept where optional files > would be maintained separately from packages, this could then be > covered in later revisions of the PMS so that in a reasonable time from > now we can properly support this and end to the rage and rage quits. I have mixed feelings. While on one hand it might be cleaner to be able to separate upstream files from gentoo files (openrc scripts, tmpreaper, logrotate, etc), the fact is that these options files do introduce functional changes of some kind. An optional file that 99% of users get installed by default that is a cron script could have a big impact on users of a package. Do we really want stuff like that happening with no maintainer involvement at all? I think cooperation makes more sense than having people work around each other deliberately ignoring things they don't like. The logic around installing these files could get convoluted as well. What if a line in the file has to be set dynamically based on something detected at time of installation? What if the file varies by package version? With an ebuild such things are straightforward - do we need essentially a second src_install just to work around the fact that somebody doesn't want us touching the main one? If this were about cleaner separation/maintenance of upstream vs gentoo stuff I could see the benefit (though it needs refinement). However, this really seems like a technical workaround for a people problem. Also, I think that Douglas is right about something - this really isn't THAT big of a problem. It really only involves a few people and a single issue. I think the bigger barrier to getting systemd units (or whatever) into the tree is people willing to do the work. I should have committed a systemd unit for mythtv ages ago, and I'm just too lazy to get it done... :) Rich