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

  • From: Adrien Destugues <pulkomandy@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 18 Feb 2015 12:19:28 +0100

On Wed, Feb 18, 2015 at 11:43:59AM +0100, Ingo Weinhold wrote:
> On 02/18/2015 11:26 AM, Axel Dörfler wrote:
> >Am 17.02.2015 um 21:54 schrieb Augustin Cavalier:
> >>Yes, you can. Copy ~/config/bin to ~/config/non-packaged/bin, and copy
> >>/boot/common to /boot/system/non-packaged/. That's all there is to it.
> >
> >That's pretty much what I did, expect that I only copied etc/, and
> >installed everything as HPKG that was in there before.
> >I haven't seen anything fail yet, and I still have the same base
> >installation from 15 years ago.
> >
> >>(If there are a significant number of users who are going to expect
> >>Installer to do this for them, we might be able to add that feature.)
> >
> >No, that's really not optional in my POV -- from a PM Haiku, there is no
> >way to access those folders, as they are hidden by the PM mount.
> >IOW the current solution is rather messy. If a config/packaged would
> >surface, though, that item would be already done.
> 
> While our plan was to create Haiku R1 with an API (mostly) binary compatible
> to BeOS R5's, I don't think we ever agreed on providing an "install over"
> upgrade path. It would have been a nice feature 15 years ago, but I suspect
> very few people care at this point.

The Installer should at least detect installing over a non-PM Haiku
partition and, if it does not handle moving the files around, at least
warn that they will be unreachable and that a clean install is strongly
recommended. We should also add a similar warning to the release notes.

In the default install process, the system directory is overwritten
already (so no problem there). common is preserved and can be moved
later on. config is a problem since Installer will try to merge it (as
it does for the rest of the disk). This leads to some confusion anyway,
as the merge tends to overwrite some of the settings, but not
everything. I think disabling that feature in Installer would be the
better solution here, as we now have a better way to update an existing
system.

-- 
Adrien.

Other related posts: