[haiku-development] Re: Haiku, Inc. in Contempt of Its Community

  • From: François Revol <revol@xxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 10 Feb 2015 02:52:22 +0100

Hi,

On 10/02/2015 02:23, Weyoun Five wrote:
> 
> On October 14, 2013, "bbjimmy" opened a bug report, located here:
> 
> https://dev.haiku-os.org/ticket/10101
> 
> In that report, he stated the following facts:
> 
> "60 to 80 percent of the third party software for Haiku has been broken 
> by changes to the file system. The user guide describes the proper use 
> of the /boot/common and /boot/home/config directory trees. These are now
>  broken. Software that expects to add a binary or lib in either tree 
> cannot. Scripting that expects binarys in /boot/home/config/bin or 
> /boot/common/bin cannot find the binary in the  
> /boot/home/config/non-packaged/bin directory."

This has been discussed at lengths many times already.

It's already 3am here so I don't have time to explain it all again, but:

- Haiku, Inc. does not participate in the development decisions, those
are made solely by the Haiku developers with commit right.

- Haiku is still alpha, and has such makes no commitment to maintaining
its own ABI or API, just the BeOS one. BeOS never had a /boot/common. It
only had the symbolic constants defined for it for find_directory(), but
the filesystem didn't have those at all.

- proper package management is the only way to handle distributing and
installing software at a larger scale that what was available on BeOS.
The fact that that "60 to 80 percent" of haikuware stuff doesn't work
anymore makes it even more visible. Zip files are still no more than a
hack. And for things made as pkg files there should be a wrapper
application somewhere to make a package out of it.

- it is also the only way one can manage porting software in a clean and
reproducible way. I did a lot of porting to BeOS and Haiku before PM,
and I ceased to count how many times I forgot which dependency I
installed and where I should point configure scripts to have it find the
dependencies it needed.

> "I don't like to have to go back and fix stuff that wasn't broken."

Nor do we.

> The bug reporter didn't ask for much, and it could have been resolved
> in a matter of minutes. All he asked for was the creation of a
> directory and read access to a few others.
> 
> It is unclear what motivated five people to respond to the bug
> report. Clearly, they had no intention of helping get the issue
> resolved. Instead, they arrogantly asserted a disingenuous argument:
> that use of hard coded paths is "broken by design."
> 
> Yet, when one looks at the inter workings of packages built by
> Haikuporter, one can clearly see that it indeed uses hard coded
> paths:

They are hardcoded to the package itself on purpose actually, to allow
installing different versions of the same package.

>  Haikuporter's incororation into Haiku was the justification for the
> destruction of numerous end user applications housed at Haikuware.
> They were all created by unpaid volunteers under the most difficult
> of conditions, destroyed by an arrogant Romanesque thumbs down:
> 
> "Package management is the future of Haiku software distribution; if
> Haikuware won't embrace that, it will go away."

Package management was not developed to piss off haikuware contributors,
not to make porting harder but to make porting easier, including for
Haiku devs and including for haikuware contributors.

François.

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 02-2015