Re: tab completion less useful now, due to sbin in path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 06 October 2008, Jesse Keating wrote:
> On Sun, 2008-10-05 at 21:54 +0300, Ville Skyttä wrote:
> > So... what can we do in order to make this happen?  Now that we have
> > volunteers, I suppose the best way forward would be to revert the change
> > for F-10 and start working on "the correct way" so that the default PATH
> > wouldn't need to be changed again in F-11.
>
> Do you really need to revert the current change just to work on
> something better?  Why can't the something better be worked on, and we
> could move to something better when it's ready.  In the mean time, we
> can continue to use the current setting.

It _can_ be done without reverting the current setting, but I think it's much, 
_much_ worse than not reverting.  After thinking about it a bit more, up to 
the point where I most likely wouldn't be interested in helping out with it 
any more.

If we work from a setup where */sbin are not in the default PATH, we only have 
to worry about existing full paths to executables we think should be in PATH 
in order to not cause regressions, most likely by providing compatibility 
symlinks or wrappers.  This way, work done results in incremental 
improvements.

If on the other hand */sbin are in the default PATH when we start the work, in 
addition to full paths and the compat symlinks/wrappers, we need to worry 
about the default PATH as well.  This is a problem because what we want to 
achieve is PATH which is kept clean of things that are not useful to have 
there, but now we can no longer remove them from it because doing so would 
inevitably break everything that has learned to expect these to be in PATH, 
or to use a full non-sbin path to it.  This way, work done accomplishes 
practically nothing (actually, we'd be making things worse by leaving behind 
a forest of compat symlinks/wrappers that shouldn't have existed in the first 
place), or we are generating regressions as we proceed.

So, I think not reverting the current setting compared to reverting it results 
in more work, harder work, worse results, and generally unnecessary default 
PATH churn (which in addition to the above is especially bad for things 
outside our control, such as /usr/local/sbin) between distro releases.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux