Date: Tue, 15 Nov 2011 15:20:45 -0500 From: Garance A Drosehn <gad@FreeBSD.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' Message-ID: <4EC2C99D.3090800@FreeBSD.org> In-Reply-To: <CAGH67wRj2iE4kGMmSU1z_8-ixeBBUMtJ5L8CWmYyePNH4yiR3A@mail.gmail.com> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <alpine.BSF.2.00.1111141745001.94325@fledge.watson.org> <20111114193434.GC2164@hoeg.nl> <CAGH67wRj2iE4kGMmSU1z_8-ixeBBUMtJ5L8CWmYyePNH4yiR3A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EC2C99D.3090800>