[haiku-development] Re: Package management - folder hierarchy
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 11 Jan 2011 20:28:29 +0100
On 2011-01-11 at 18:24:18 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
>
> Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> > We do not have a union-fs implementation currently (and during my
> > research
> > I've read educated comments about why those are surprisingly hard to
> > get
> > "right"), so I started looking into the restructuring approach.
>
> While I wouldn't mind some restructuring, I think a union-fs is still a
> worthwhile target.
One problem with a complete union-fs over the package tree is that it would
be very easy to mess up, as any write access (whether intended or not) will
copy-up the file from the package-fs to the writable layer. If you then
update the package underneath, someone would have to make sure to clean up
the respective files in the union-fs. Solvable, I guess, but not very nice,
IMHO.
Alternatively, we could union-mount just the writable folders of the
package-fs tree. That would still leave the problem of a union-fs behaving
somewhat strange: If you drag a settings file from the union-fs to Trash,
it will still be there afterwards (this time the version from the
package-fs) or the one from the package-fs would be hidden (by a white-out
in the union-fs).
I didn't spend that much time thinking about it, but I'm no longer
convinced we'd actually win much by using a union-fs for that purpose. One
good aspect of a union-fs, of course, would be that it would make fiddling
with the package contents easier (let's say to replace a library
temporarily).
> Still, it would be nice to find an alternative approach for the time
> being, and make it pretty much optional that way.
> Also, I have no good idea on how to have drivers in packages else.
Are there many types of drivers that would be required before the
package-fs could be mounted? If there are not, we could use something like
an initramfs for makeing those drivers available to the bootloader,
couldn't we?
> > 1. common contains both Haiku-specific software as well as ports [as
> > is now]
>
> I think there can only really be 1., as for some ports, it will be hard
> to determine where they should be put. For example, ScummVM should
> probably end up in /boot/apps/, but is a port, too. Or should only
> properly ported ports end up there? :-)
Yeah, that's a good point and precisely what made me add number 1 alongside
of number 2 (which was the only one I mentioned in the blog entry) :-)
>
> > /boot
> > |-apps -> [symlink to /boot/common/pkg-tree/apps]
> > |-common
> > |---cache
> > |---packages [dropping a package here will activate it
> > system-wide]
> > |-----history [contains info required for rolling back in
> > time, used
> > | by package manager]
> > |---pkg-tree [mountpoint of system package-fs, contents of
> > the
> > | packages in /boot/common/packages appear here,
> > the
> > | folders follow "Haiku filesystem hierarchy" (to
> > be
> > | defined, an example given below)]
>
> I think this needs a better name, although, I struggle to find one
> (besides the more verbose package-tree, that is).
Agreed, maybe we should use something generic instead, e.g. 'vault'?
> > |-----data [+ what used to be in 'share']
>
> Where is that actually coming from? Using symlinks from pkg-tree?
Hm? data is simply a folder that's part of the pkg-tree, representing the
union of what currently is in /boot/common/data and /boot/common/share.
>
> > |---settings [+ what used to be in 'etc']
>
> Unfortunately, "etc" isn't just composed of settings, a large part is
> actually "data" or even "bin".
That should be solved by moving those files to appropriate places during
individual ports. All software that I have seen lately can be persuaded to
put their files into appropriate folders, we just have to fix the rest :-)
>
> > |-home
> > |---config
> > |---packages [dropping a package here will activate it for
> > user]
> > |-----history [contains info required for rolling back in
> > time]
> > |---pkg-tree [mountpoint of user package-fs, contents of the
>
> I think both, packages, and pkg-tree should go under config/ as that's
> the equivalent to /boot/common.
Correct.
> > |-system [unchanged, contents can be updated via package
> > | manager by actual installing (unpacking) of
> > either a
> > | complete "system" package or sequential
> > "system-fix"
> > | packages]
>
> Even this needs package descriptions, though, to be able to let 3rd
> party depend on certain versions (for example, to be able to have the
> GCC2 support optionally available via a package in the far future).
Sure, the system packages would have to be kept somewhere on disk, at least
stubs of them containing just the package metadata.
>
> > |---develop [moved here from /boot/develop (except for the
> > 'tools'
> > | folder), as it depends on the current system -
> > the
> > | tools subfolder (gcc & binutils) will be spread
> > out
> > | over /boot/common/pkg-tree]
>
> Makes sense, especially because there is not much interesting user
> content there.
> Also, we would still need /boot/common/develop/ to place the includes of
> development packages.
I imagined those would appear in /boot/common/pkg-tree/include. They're
just packages, too.
> > |---optional [moved here from /boot/optional, as the
> > contents
> > depend on the system]
>
> Yup, even though I wouldn't mind to remove it completely, and have its
> contents as separate packages.
That's fine by me.
cheers,
Oliver
Other related posts:
