[haiku-development] Re: [Haiku PM] compatibility with software from Haikuware
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 25 Sep 2013 12:19:25 +0200
Hi,
On 25.09.2013 02:31, Jessica Hamilton wrote:
Whilst there's already a physical file-system layout to [mostly] match
what should be expected from a non-PM point of view, the whole
"non-packaged" thing completely takes away from the simplicity of Haiku.
And given that you've already implemented the equivalent of a union
filesystem, perhaps the ideal would be to get rid of the read-only
directories, and use the "non-packaged" directories as writeable overlays.
It doesn't make sense to me. How can you for example delete a file,
which is actually part of a package? You have to think it through, what
"writable" actually means. What use-case does it serve to be able to
delete random files from packages and screw things up?
Now, if I understand things correctly, it's already possible to shadow
files from packages by placing modified versions at the equivalent place
in the non-packaged hierarchy. And there is even a use-case for that,
which is for example testing a new libmedia.so, or replacing freetype
with a version that supports sub-pixel rendering.
Of course, if you accidentally replace a working library with an
incompatible one... let's assume the size of a data structure changes in
the library because you turned on a compile time feature... it just
highlights the dangers with this approach of patching the system up.
Two contrary forces are at play here: On the one hand, package
management is expected to always result in a consistent, working system
where everything indeed fits together. On the other hand, some people
want to mess with stuff however they want. It surely wasn't easy to
figure out a solution that accomodates these use-cases, but that's what
you are looking at.
This way, stuff could still be manually written to the packagefs mount
points, with the writes being transparently passed through to the
underlying filesystem under "non-packaged".
Of course, I'd expect files from packages themselves to still remain
read-only. A possible upshot of this may be that you could even shadow
files that come from packages. You could go so far to allowing what
appears to be changes to package files by transparently copying them
into the underlying filesystem and making modifications there.
Huh? Files are read-only but you can shadow them? How, if you only have
one visible folder and the files therein? Think it through and you may
just arrive at the conclusion that what you see now, is exactly the only
way it can possibly work. Or am I missing something?
Best regards,
-Stephan
Other related posts:
