From owner-freebsd-arch@FreeBSD.ORG Tue Nov 15 20:20:48 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E75C106564A for ; Tue, 15 Nov 2011 20:20:48 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB518FC1D for ; Tue, 15 Nov 2011 20:20:47 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id pAFKKj6q032705; Tue, 15 Nov 2011 15:20:46 -0500 Message-ID: <4EC2C99D.3090800@FreeBSD.org> Date: Tue, 15 Nov 2011 15:20:45 -0500 From: Garance A Drosehn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 3.10 (***) [Hold at 12.00] APOSTROPHE_OBFUSCATION, COMBINED_FROM, J_CHICKENPOX_53, RATWARE_GECKO_BUILD X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228 Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 20:20:48 -0000 On 11/14/11 4:45 PM, Garrett Cooper wrote: >> Just because certain aspects have so far not been worked out completely, >> doesn't mean the idea as a whole is a bad thing. And if it turns out to >> be a bad thing, then so be it. At least it has served as a lesson. Maybe >> it's worth asking yourself this question: "say, we were to merge sbin >> with bin, what kind of problems can we walk into and how should they be >> resolved?" >> > Having written a few shell scripts and debugging others' -- I can > speak from experience and say that there are folks who do one of the > following: > > 1. Hardcode paths to utilities (/usr/sbin/sysctl comes to mind). Maybe > for optimization; maybe to avoid alias'ing, etc. > 2. Use which / command -p / etc to divine where their binaries come from. > 3. Hardcode PATH to a restricted path to ensure determinism. > 4. Just dash it all and call commands without any predivined path. > 5. People might have come up with tricky ways of determining real > files from symlinks in their scripts or other programs in order to > 'divine' their existence. > 6. People have come up with interesting path overlaying; this is > especially true in larger companies where there's 15+ years of > development history, e.g. my previous employer. The difference between > one binary and another is the difference between your application > working and not working. > > Please be careful because I'm sure your changes are going to break > items 1., 2., 5. and 6., which is going to break a lot of 3rd party > scripts, binaries (vendor code like the mergepoint BMC update > utilities), ports, and packages in inexplicable ways. > > Anyhow, back to your regularly scheduled bikeshed. > I agree completely with all the concerns listed by Garrett. There are a lot of changes which might be nice if we were starting from scratch, but which at this point would require much more work than they're worth. I expect this is one of those changes. I expect that because I don't see this as producing enough benefit for all the disruption and mysterious failures it will cause. If this change breaks some autoconf script, for instance, that will disrupt and distress a lot of end users who ARE NOT DEVELOPERS, and it also will piss off all the 3rd party developers who will be told to stop whatever they were working on just because the FreeBSD project wanted to shuffle around the location of a lot of binaries. And there's absolutely no way that you can convince me that ever single poorly-written-but-working autoconf script will work correctly after making a change as disruptive as the one you propose. I've spent too many years debugging scripts which made important decisions based on utterly stupid criteria which just-happened to work. This might be a project which is done gradually over a few years, but it is not something which must be committed to right now as some high-priority project. I'll pick red for this bikeshed, because that's what our users will be seeing if we rush into a mass migration of all of sbin. IMO. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu