9base in Fedora?

Stephen John Smoogen smooge at gmail.com
Wed May 25 21:31:46 UTC 2011

On Wed, May 25, 2011 at 09:36, Bill Nottingham <notting at redhat.com> wrote:
> Petr Sabata (contyk at redhat.com) 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 at lists.fedoraproject.org
> 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

More information about the devel mailing list