[haiku-development] Re: I suggest a vote on 3 items

  • From: Adrien Destugues <pulkomandy@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 2 Sep 2015 21:40:16 +0200

On Wed, Sep 02, 2015 at 03:00:10PM -0400, jimmy@xxxxxxxxxxxxxxxx wrote:

Thank you for your response. Personally, i am all for package
menagement! I love it and I think it adds a great benefit to the Haiku
Project. But was all this really necissary for package management?
That's all I'm saying, and the response is "Well this is how we did it
and that's that". I feel that the implimentation of it needs improvement
and it isn't being addressed. It CAN be done in a way that does not
require compatibility workarounds, read-only structures and dividing the
community.

Compatibility with what? Please provide actual examples of applications
that are broken by this. I have requested this several times to many
people complaining about breakage and never got actual examples of
applications that are broken by the change of directory layout.

Time can be spent right now to implement the "Hold The Shift
Key" feature so that the read-only thing doesnt turn people off and to
leave the option for people to do things the old way -perhaps with a
BAlert that pops up with a warning suggesting to use package management
instead of the legacy package...

It's not read only just to annoy users. There is a performance problem
in allowing the packaged folders to be writable. It would make Haiku
super slow if we did that, and this is why the idea, however nice it is,
has been dropped. This time even some of our most skilled developers
couldn't find a solution with acceptable performance.

So, we could have a hold the shift key dialog, and then what? Writing to
the system directory is not going to work, no matter how hard you try.
Not because "some developer decided so", but because there is a
technical issue for which we haven't found a solution. Knowing this,
what can we do when you hold the shift key? I can think of one solution,
which would be to redirect the writes to the non-packaged directory.
But, what problem would it solve? You can't edit an existing file this
way.

I think being able to customize and tweak the system is important, but
it is not going to work in the PM world by directly replacing the files.
What the Haiku team has been working on, for the past few years, and
even before the work on PM was started, is extracting as much as
possible out of Haiku. Since 2012 the number of lines of code in the
Haiku repository has halved. All this code was moved into optional
packages, and now into packages, which you can install, remove, modify
and update at will. We are continuing this work and the next step is
splitting the big haiku package into a set of smaller ones. This way you
will be able to replace coherent parts of the system for testing and
customization purposes. And we won't even need that "hold shift to
proceed" dialog.

Just because time and money was spent
doesn't make it the best way of doing things. Probably 99% of the work
done could still be used and the 1% change in code would make people
happy (go ahead Adrien, yell at me for that one.. I'm just trying to get
people to think in creative possibilities..)

Yes, we all said package managent was a Must Have, and it is! However, I
think many people would agree that it is being implemented in a
sub-optimal way. If everybody knew (dev's and non dev alike) that the
choices made would bring so much trouble and delays to the project,
things would have been different.

I can agree on the delays, but not on the trouble. My use of Haiku is
much easier and safe than it used to be, knowing that I can update
software, test it, and if things don't go well, roll back to an older
version from the boot manager (seriously, this is an awesome feature!).
In the days before PM I often "killed" my install because I installed
some package that was designed for a gcc4 system in my gcc2 one and it
overwrote some libs, or many other similar mistakes.

There were some rough edges when the package system was initially
merged, as with any new code and big changes like this. There was an
unexpected amount of work to get everything going, but it is now behind
us.

There are a few changes that require some adaptation, like these
non-packaged directories. However, I think the current implementation
for this is in line with my Haiku philosophy (not everyone has the same,
probably): instead of making things complex and trying to hide the
complexity, we have something that is reasonably simple and you can see
how it is done without having to dig in the code. A "transparent" system
where you can write to the directory and it stores the data in some
special place would be a "hiding the mess" approach, which I think is
better avoided. There may be a solution that is simple, does not have a
big performance hit, and is easy to understand and use, but I can't
think of one. Do you have suggestions on what we could do?

There are other parts, like the way DeskBar is populated, that are not
in line with this. However, there was a lengthy discussion about it on
the ML and I don't think a better solution was found (a proposal using
queries was interesting, but didn't allow for customization at all).
On my side, the result is I don't use the deskbar menu all that much
anymore and have installed LnLauncher, where I can manage icons the
way I want.

--
Adrien.

Other related posts: