On Wed, May 25, 2011 at 09:36, Bill Nottingham <notting@xxxxxxxxxx> wrote: > Petr Sabata (contyk@xxxxxxxxxx) said: >> > >> There is no reason not to put them in /usr/lib(64). That's where common >> > >> binaries such as firefox, java, etc already reside. They all have magic >> > >> env variables to define their root for scripts and >> > >> symlinks/wrappers/alternatives in /usr/bin >> > > >> > > >> > > In this case, though, there wouldn't be wrappers or scripts in /usr/bin. >> > >> > Ok looking at how convoluted we are having to get this package in.. >> > what are the reasons to have it in Fedora? Would some other way of >> > producing them having them available be there? Who is going to benefit >> > from them being there? Etc >> > >> >> Simply to make Fedora better. I'd like to make those available for our users. >> There are currently no other packages relying on this set (or rc, to be more >> specific) in Fedora. That could change in the future, though. > > The question is - why does having incompatible plan9 implementations of > common commands make Fedora 'better', outside of "having more stuff"? I vaguely recall the headaches we had in Rawhide at one point where we tried the experiment of moving to OpenBSD implementations of applications because several customers thought they were more secure. And they were in the OpenBSD environment. In the Linux environment they were very buggy and many many applications did not work the way they did in either OpenBSD or with GNU tools. We also tried putting them in an alternative path at one point, but this also caused issues for those users. > Bill > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
