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 F1E5D1381F3 for ; Mon, 24 Dec 2012 22:24:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 27B7C21C038; Mon, 24 Dec 2012 22:24:23 +0000 (UTC) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 98AB421C024 for ; Mon, 24 Dec 2012 22:23:14 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h16so7076034oag.5 for ; Mon, 24 Dec 2012 14:23:13 -0800 (PST) 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 :content-type; bh=syu+X154PBC41nLtUQvn87N3F5xLRgX+MZDAnLF/Uc8=; b=iaeiSfUra1FQrLifmK2QNNCggqjbDU3OH5XU5G52kI15Bp9WzkNHfzbgcmUz8hfNrM bI6O6NaXZZ7kX20GdpH2Iv3/Jf7M7cmRj5QtKtq5Y+lZ6Y4eJ1YCuFNnEQuQmMhC7ahJ UNM/V3rAIBtBohLYI50QrgbKoMa8djFO3ti9PsT5RNrfZTeZyGIZtiJTnnwD0qdWhxUS u62pTRVEgibvYPPKBnmY8md9jBCCt5JHkWcx+we85w/T4Ixc5u81VF5xQSaF0oIrTZYs oGXpSWE2zoGVrtYYprXK8EUj5nNnqNTiAcSdVlus21la5jvnohf72Mm/ULw7B+lXDgzh PZOw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.60.6.226 with SMTP id e2mr7467770oea.56.1356387793758; Mon, 24 Dec 2012 14:23:13 -0800 (PST) Received: by 10.76.20.243 with HTTP; Mon, 24 Dec 2012 14:23:13 -0800 (PST) In-Reply-To: References: <50CB1942.3020900@gmail.com> <50CB4A3C.1030109@gmail.com> <50CB5406.7040404@gmail.com> <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.com> <20121218163332.7956f31a@khamul.example.com> <87txrd6pb3.fsf@ist.utl.pt> <20121223182037.1553813f@khamul.example.com> <87bodk7lb6.fsf@ist.utl.pt> <20121224085528.56f535ec@khamul.example.com> <50D85167.9060309@gmail.com> <20121224204817.335033c6@khamul.example.com> <50D8B467.4080100@gmail.com> Date: Mon, 24 Dec 2012 17:23:13 -0500 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: bc1e2322-1cb5-4134-bb5f-1c7b22637ac6 X-Archives-Hash: f339e428c798e3e43c1ea8ef83db6870 On Mon, Dec 24, 2012 at 4:43 PM, Mark David Dumlao wrote: > On Tue, Dec 25, 2012 at 4:00 AM, Dale wrote: >> If I put / on LVM, I need a init thingy. > No you don't. You could use a boot partition. Or grub2. I don't remember reading /boot as a suggested solution. Frankly, that's an interesting idea. And I'd completely forgotten about grub2. That actually sounds promising. > >> So, worked for ages, then it breaks when people change where they put >> things. Answer is, don't change where you put things. Then things >> still work for most everyone, including me. I'm not a programmer nor am >> I a rocket scientist but even I can see that. If I can see it, I have >> no idea why a programmer can't other than being willingly blinded. ;-) > > You have no idea why it's being deprecated because you STAUNCHLY > REFUSE TO READ why so, even when it's blatantly being spelled out over > and over again why it's being done that way. > > recap: many packages depending on udev keep putting stuff in their > udev rules that depend on binaries in /usr. It's not udev's > responsibility to fix or maintain these packages. Nobody ever argued that it was. The reason this argument is so heated on this list has its roots in an earlier discussion, going back about a year and a half ago. It started when systemd was brought up as a response to one problem or another a few times, and critiques and arguments against it were often met with what read like bad-faith arguments in dismissive tones. Elsewhere, systemd's architect met criticisms in a similarly dismissive fashion. This made some folks (myself included) wary of systemd and anything it controlled, simply because it seemed useless to try to participate in rational critique. Then udev announced it was going to merge into systemd's source tree for better developer interop. At that point, some of us feared (rightly, as it turned out) that the top-down, my-way-or-the-highway attitude from systemd would take over udev, and that the close proximity in the source tree would make it difficult for the udev component to exist independently and in a stable fashion. (Where 'in a stable fashion' means "doesn't become a moving target for anyone apart from systemd trying to interoperate with it.) I remember feeling like I'd just seen a train derail, and was watching a large, slow moving train wreck. Then came the declaration of "separate /usr is broken", much to the dismay of those of us for whom that configuration truly did work just fine. Yes, we understand that, in an overly complex system, dependencies can get mixed up and you need to resolve that somehow. (Personally, I think that any binary outside /usr that depends on binaries or data inside /usr is broken and should be fixed.) Then came the decision to move udev inside /usr, forcing the issue. Now, it'd been long understood that udev *itself* hadn't been broken. The explanation given as much as a year earlier was that udev couldn't control what *other* packages gave it for rules scripts. OK, that's not strictly udev's fault. That's the fault of packages being depended on at too early a stage in the boot process. And, perhaps, hotplug events for some devices _should_ be deferred until the proper resources for handling it are available. I can think of at least a few ways you could do that. And, yes, this was a problem systemd was facing, and wasn't finding a way out of. (Why? I still don't know. Maybe they didn't want to implement dependency declarations or demand that packages impement partial functionality to reduce initial dependencies.) Still, instead, the decision was made by the systemd/udev management to give udev the same _intrinsic_ dependency faults that systemd had, and udev, previously, hadn't. Previously, udev was a tool that you would use, and you would be expected to be wise while using it. Now, udev is a tool that's lost some of its power in order to force an environment more suitable for systemd. -- :wq