Re: Using unionfs to handle clashes between AP and the native package manager (e.g. .RPM .deb)

On Tue, Jul 21, 2009 at 3:56 PM, Pablo Garralda<[email protected]> wrote:
> Hi all,
> =C2=A0=C2=A0=C2=A0 I the F.A.Q. section "I bet autopackage sucks because =
..." in the third
> paragraph says:
>
> "[...] In future it's possible that autopackage will register with the
> package manager databases to prevent this, or alternatively *a distributi=
on
> could provide support for additional prefixes (eg via unionfs) one of whi=
ch
> could be used by autopackage for its own files*. [...]"
>
> - Can anybody elaborate about using unionfs for "support[ing] additional
> prefixes"?

(I did not write that FAQ entry, but this is my guess on what it means)

Unionfs allows two or more directories to be combined into one view.
This means that you could create for instance /allbinaries and union
mount /bin, /usr/bin and /usr/local/bin into that single folder. All
files in these three directories would show up as if they existed in
the /allbinaries directory.

http://www.filesystems.org/project-unionfs.html

> - What kind of problems this solution will attack?

It would not require us to put files into the /usr namespace which
would take away the problem of colliding with distro installed files.
We could for instance install all autopackages into /opt/autopackage
and just unionmount files into their corresponding system location

> - Is there any additional burden for the App developer to use this? (e.g.
> Should the binary be relocatable?)

Yes, binary relocation would still be needed for things like $HOME installs=
.

But other than that, no there would probably not be any other burdens
than what autopackage already requires from the developer...

> - How can I configure autopackage installer to use such a prefix by defau=
lt?

We don't have anything like this in place and no immediate plans to do
it. This FAQ entry was probably more of a brain dump of what could be
done theoretically...

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]