Am 15.02.2015 um 19:06 schrieb Jim Saxton:
The proper way to accomplish this would have been to leve the directory system as it was under the home directory but add a "Packaged" directory tree. ~/config/Packaged. This way anything in the "packaged" directory would be read-only, and anything in the normal directory tree would stay read/write. This way, an app that drops libs in say ~/config/lib would still work without needing to be packaged. This would have had nothing to do with how PM works, only with the directory naming and presentation to the user.
From the POV of the implementors of PM, there was no reason to keep the old paths intact, as *nothing* should have used fixed paths in BeOS -- properly written software will just continue to run on Haiku, and there are enough examples of that. That the reality looks a bit different is unfortunate, but software that is still being maintained can be fixed, or repackaged if it's just a packaging problem. That's actually the same no-legacy policy people liked about BeOS (even though it was almost never completely true).
You know, PM is supposed to be it. "non-packaged" is something that shouldn't ever be needed on a normal non-developer system. I could imagine not even including those paths in a future release (ie. create them on demand only).
So many frustrations, conflicts, and bad relations could have been avoided.
I'm also a software developer, and I even didn't go through all the pain to update my software for the most part (but then, my software is pretty much outdated, anyway). I liked the "Install here" symlink directory within the ZIPs I distributed. Those no longer work, unfortunately. I knew that this may happen one day when I packaged my software this way, too, I just didn't bother. But I know that potential Haiku users will value my software in a HPGK much higher than having to download and install it manually.
Anyway, change may cause pain and grief. At least it's a change for the better.
Again though, this is water under the bridge at this point and not wrth persuing.
There hasn't been a single release with PM yet, nothing is set into stone for real yet. Sure, it would be a lot of work to change things now, but that's just a hurdle, not a show stopper. Even the original plan to have the old paths writable again would still be possible (sure, there is a slight performance hit, but that wasn't the reason this wasn't implemented -- it just wasn't deemed worth the effort). Patches are certainly welcome! We could even make the unionfs-config part of a BeOS compatibility package for those that are concerned about the performance penalty.
As an application developer, you aren't supposed to target nightly builds, anyway. The fact that you can is just because we happen to be an open source project :-)
Bye, Axel.
