[haiku-development] Re: Some thoughts on package management

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Fri, 18 Oct 2013 10:35:37 -0400

It's hard for me to judge what are legitimate complains and what are
complaints that are transient and will go away as the bugs get worked
out and software gets repackaged so please bear with me.

I like what I've seen of the new stuff that package management brings,
and we all knew that installoptionalpackage wasn't going to be a
permanent solution.

That being said, it is not okay to break existing software and I think
that is where most of the complaints lie. How can we get existing
software to work again unmodified, and, baring that, what is the
easiest path to making the rest work again?

On Thu, Oct 17, 2013 at 11:50 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 10/17/2013 11:25 AM, Adrien Destugues wrote:
>>
>> So, while most users can get away with having /boot/system read-only
>> (that's a good thing despite the incompatibilities it has with some
>> software and/or installers), most of them don't agree with having
>> home/config read-only. I agree on that, and think we should leave the user
>> manage its home directory the way he needs it.
>
> There's home/config/non-packaged for exactly that purpose.

This doesn't appear to be a sufficient answer for the applications
that no longer work because they expect home/config to be writable. I
don't understand how those applications can be fixed short of
repackaging them which is not a very good answer because it is too
much work and simply cannot be accomplished in a reasonable timeframe.

For .pkg files maybe we can get the files to install in non-packaged
instead, but for other software what's the answer? The compatibility
problems don't seem to have been fully addressed.

If home/config were to be made writable what else would need to change
to continue to make package management work as intended? How would
that affect things?

>> Having a package-managed home/config is useless. The purpose was to mount
>> home-grown packages there, but since this isn't looked up by the
>> development tools, it's not handy to drop a library or devel package there
>> and have it working immediately.
>
> As written before, that is just a question of adding the paths in question
> to the respective environment variables.

It seems like a decent design decision to make /boot/home mirror
/boot/system but perhaps that isn't tenable?

>> Finally, I'd suggest mounting all packages in /system, no matter if they
>> come from /system/packages or /home/config/packages. In a multiuser system
>> this would mean each user sees a different /system directory, but it
>> allows
>> installing custom packages for each user in a transparent way.

Could we make /boot/home/config writable and keep
/boot/home/config/packages/ removing /boot/home/config/non-packaged
and having the packages in /boot/home/config/packages get merged with
those in /boot/system?

> IIRC that's actually how I thought things would work when I originally wrote
> packagefs (feature removed in 6978941aac85ea329a8552253f384924dcccd1b3).
> Particularly when we go multi-user, this adds significant complexity to the
> implementation, makes it much harder to understand things (e.g. that system
> programs won't pick up entries provided by packages in a user's home), and
> probably wouldn't allow installing multiple incompatible versions of a
> package.

Okay, what about as an alternative just get rid of /boot/home/packages
altogether and make it so that all packages are installed in
/boot/system? This would eliminate the ability to have per user
installed packages, but, I can't currently think of a better way.

>> This allows
>> the user to keep untested packages in /boot/home, and possibly boot in
>> safe
>> mode without enabling those if something goes wrong.
>> Yet, it keeps the FS
>> hierarchy simpler, with a single package-FS managed directory in the
>> system.
>
> Unfortunately bought with additional complexity and obscurity.

I hear you, I just don't know the answer right now.

Other related posts: