Philippe and Francois have already responded to a lot of the stuff in this post, so I'll only respond to a few others I noticed.
On 2/9/2015 8:23 PM, Weyoun Five wrote:
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."
{CITATION NEEDED}
No, seriously, where does that figure come from? Did you take a
statistical sample of all the 3rdparty software you could locate? Did
you try every single one? Are you sure they are really broken, and not
misinstalled due to a bug in PackageInstaller (which has had a lot of
bugfixes in the past few months)?
Why are we at fault anyway? If people writing these applications and scripts really did do such a shoddy job and completely disregarded the notices / warnings in the API docs for directories, why are we suddenly to blame for making a change that is supposed to be non-breaking?
TLDR: I refuse to accept this statement as factual without a listing of applications you have found so far that are broken. I will be very surprised if there are a substantial number of them that are affected by this and are closed-source.
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.What directories can't you read? And as stated in the ticket, you can "mkdir /boot/common" and "/boot/beos" yourself.
Yet, when one looks at the inter workings of packages built by Haikuporter, one can clearly see that it indeed uses hard coded paths:readelf -d msgen Dynamic section at offset 0x2bb0 contains 23 entries: Tag Type Name/Value0x00000001 (NEEDED) Shared library: [libgettextsrc-0.19.2.so] 0x00000001 (NEEDED) Shared library: [libgettextlib-0.19.2.so]0x00000001 (NEEDED) Shared library: [libncurses.so.5] 0x00000001 (NEEDED) Shared library: [libintl.so.8] 0x00000001 (NEEDED) Shared library: [libiconv.so.2] 0x00000001 (NEEDED) Shared library: [libroot.so]0x0000000f (RPATH) Library rpath: [/packages/gettext-0.19.2-1/.self/lib:/packages/ncurses-5.9-10/.self/develop/lib:/packages/libiconv-1.13.1-6/.self/develop/lib]
You missed an extremely key point here: it uses a hardcoded path /that will not and cannot change/, and is the "right way" to do things, as it's by design not by "oh I'll just use a hardcoded path because I'm lazy". Which makes a huge difference.
Haikuporter's incororation into Haiku was the justification for the destruction of numerous end user applications housed at Haikuware.
What applications were destroyed? {CITATION NEEDED}.
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."
From what I see it *has* embraced it (at least partially), as HPKGs are starting to show up all over the place. But yes, Haikuware still refuses (or maybe it technically cannot?) provide a package repository for people to "pkgman add-repo" to. Which is why we have started adding most of these packages to our own "haikuports" repository.
Actual complaints are welcome. But all I see here are some really general criticisms that might be valid if there was data to back them up. I haven't seen any of that, so, {CITATION NEEDED}.
-Augustin
