[haiku-development] Re: software organization/installation
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 16 Feb 2009 21:12:46 +0100 CET
Stephan Aßmus <superstippi@xxxxxx> wrote:
...
> In laymans terms, the pkgfs will "insert" fake
> files inside the real file system, which are really
> located inside packages, correct?
Yup. A fully virtual filesystem, which gets (re-)
populated freshly from a set of packages at bootup
and on further package addition.
The actual set of packages will have to be stored on
a the boot filesystem.
The pkgfs should not insert into or alter a real filesystem
if it can be avoided, and not obscure a real filesystem,
unless desired and set up that way.
I'm regarding the packages and their contents as read-only,
and I suppose this might have issues.
> What happens when two packages contain a file with the
> same name at the same location, but the actual file
> contents are different?
Conflict description data should be published by the
pkgfs, packages should be attributed as conflicting,
and the package added last would be disabled.
Ideally the package manager should predict the conflict
before-hand and inform the user that the packages can't
coexist. I'm hoping this will not be a common occurence.
Automated builds should check package collections. (Think
NetBSD pkgsrc-2008Q4, or packages in a BeBits-pkg-repo)
> It may look like the point of pkgfs to overlay the
> file depending on what application is being launched.
Differing per-process views of the filesystem doesn't
seem like a good idea to me. (I know it's been done,
but is it in line with our goals? Applications could
risk presenting their different views of the filesystems
to the user.)
In case of conflicts I suppose you would have to
choose which package to keep for now, wait for updated
packages, or fix the package(s) and see how it works
out when new packages get distributed.
Ideally the repo(s) should coordinate enough to avoid
conflicts as much as possible.
...
> Another interesting problem is installing software
> manually from source. How would that work? Would you
> require building packages instead of "make install"?
I don't see a conflict here. You could make install
on your real filesystem and use the result, or you could
use --prefix=some empty folder, add some pkg metadata,
archive it with relative paths and use it through the
pkgfs.
There might be issues with pkgfs overlaying your "real"
/bin and friends, if software want to write, rename or
alter the files that live in packages, which I hope can
stay read-only. So perhaps a separate directory structure
dedicated to the pkgfs is best. Virtual and not overlaying
a physical filesystem. Not using any of the posix folders
to avoid problems. Maybe. I don't know.
/Jonas.
Other related posts:
