From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SI0qq-0006gi-TZ for garchives@archives.gentoo.org; Wed, 11 Apr 2012 16:57:01 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6EC89E0DCB; Wed, 11 Apr 2012 16:56:41 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 48B09E0D96 for ; Wed, 11 Apr 2012 16:55:50 +0000 (UTC) Received: by bkwj4 with SMTP id j4so982489bkw.40 for ; Wed, 11 Apr 2012 09:55:49 -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=0RaL5qBx5mJD70C/zFhuwQubDFCoTiA39v/xJD/eVCQ=; b=i5K3jzFozGHZgbl65thCbSSxA4ZHcyX4T7NqZ2PeVqcX2+iNBIxJ5/z56XbFfu8d1V ZMXMInmJq/NduOyAjUXShPWULtChNFsoHDOSB6cJzh8G089MMOqZJKS4wp6y7Z2ePnoW /tF0jleNWbsMATo0r1A6e5p1/ndHjPfcGHy9kaIcOKRWx2LrE24PGwWTFOQcu75G0ruF tGd/jDs7B5+d6ddJbiacv/nOlZuyCnDpB7q3tzBW73uSGdgGdFIKux/Z/szTiX443VLL mNn6jWKvZqhEpOsPwYmFE6ZrUUTLB5GFbIN9CtuQiFyV7zun97KuGADEw0kNZi3/AHFv julw== 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 Received: by 10.204.13.72 with SMTP id b8mr6157284bka.105.1334163349330; Wed, 11 Apr 2012 09:55:49 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.226.77 with HTTP; Wed, 11 Apr 2012 09:55:49 -0700 (PDT) In-Reply-To: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> <4F833687.4040004@gentoo.org> Date: Wed, 11 Apr 2012 12:55:49 -0400 X-Google-Sender-Auth: NgYkHTHTPpyKCUfUmqo3jvkuhPg Message-ID: Subject: Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 5b0b0a4b-fd96-4bf5-b8a0-7aee0277aaed X-Archives-Hash: eba6dcc8399cd433cc0e2996a99d53f1 On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote: > That might be true for some Linux-only packages, but I really find it hard > to believe that any upstream targetting more than one OS (just adding a BSD > is enough) with software that could be considered critical (I for one would > include all POSIX utilities as well as basic stuff like mount, fsck and > lvm2) would want to ignore this kind of thing; if the build-system is > ignoring configuration, it's a bug. The issue is that if udev requires libfoo, then libfoo must not be in /usr. If libfoo is libx11 or dbus or some other complex library, that will pull in a bunch of other stuff as well. However, I doubt that the maintainers of all those libraries would consider them boot-essential, so they may not be inclined to make the move. Obviously we're not there now, but it is a possible consequence of moving in this direction. Keep in mind that systemd in particular does not aim to be cross-platform - they advertise this as one of their core features. Since tight integration is their goal that could slowly bring in a lot of other stuff. The main platform pushing it along is Fedora, and they're aiming to move everything into /usr, so this is a non-issue for them. > I read the decision from the Council to be "we will continue to support the > traditional split /usr eg with lvm, and no initramfs" and a Council member > put himself forward to maintain patches to udev to ensure that going > forward, since it is needed in his employment. > > Given that we can do it with initscripts, and don't need to fork udev at > all, what's the problem? I can't really comment on what the decision from the Council actually was. However, maintaining patches to udev is effectively the same thing as forking it. Right now it probably isn't hard, and over time that could change. The only time patches != fork is if the patches have been submitted upstream and are likely to be merged. In any case, it isn't a crisis now and waiting a little to see which way the wind ends up blowing probably makes sense. Rich