Re: The objectroot FHS

On Tue, Apr 30, 2013 at 5:30 PM, Liam Proven <[email protected]> wrote:

>
> It is an interesting proposal and I see where he is coming from, but
> it seems to fail on one count, for me. AIUI part of the plan for Gobo
> was to make it _easier_ than old-fashioned Unix - something Time
> Lehtinen mentions.
>
> His plan may be more logical for modern systems, but it is _not_
> simple. It looks rather complex and difficult to me, TBH.
>


That's true, but that might be fixable by applying some Gobo-sensibilities
to it.

OTOH, I am not 100% sure is really is a good idea. It seems very awesome at
first, but there are a couple of things I question about it.

First, does it make sense for users to be independent of the the host
system? The way things are today it is the host that designates the users
it recognizes (via passwd or such). Can multiple hosts effectively share a
set of users? And how does that play out across the network where different
machines have different users?

Likewise, I really like the idea of org too (though I would call it
`vendors` instead), but having programs outside the host raises the issue
of architecture and build flags. Somehow the org programs have to
internally segregate for different archs for possible use by different
hosts that have different configs. e.g. say one host is a i386 build of
Debian with selinux (or something like that) and another is a Gentoo amd64
host with different default compile flags. How can they share programs? It
doesn't seem like we can really separate the host from the vendors (at
least not for compiled code) b/c it would just have to be built
specifically per-host anyway. We'd end up with something like:

    /hosts/
      debian1/
    /org/
      foo.org/
        fooapp-1.0.0/
          builds/
            debian1/
              bin/
              lib/
              ...


Isn't that the only way we can ensure the software is built properly to
operate on a host? If so, there isn't much advantage to separating them.
However, there may be one possible way around it. The org locations could
use a cryptographic hash of the build dependencies. This is an idea
pioneered by the Nix package manager. So we get something like:

    /hosts/
      debian1/
    /org/
      foo.org/
        fooapp-1.0.0/
          builds/
            x8kdjf-993i54-0900ffs-0909504-blah-blah/
              bin/
              lib/
              ...

The ugly number is a computed checksum of the arch, dependencies, and
compile flags used to build the app, so as long as any host is configured
as such then it could use that build.

        trans.

_______________________________________________
gobolinux-users mailing list
[email protected]
http://lists.gobolinux.org/mailman/listinfo/gobolinux-users