Re: The objectroot FHS

On Wed, May 1, 2013 at 2:42 PM, Sepero <[email protected]> wrote:

>
> I am not sure the naming clash issue is that important though. I could
>> conceive of just having users, groups, orgs and hosts all in the toplevel
>> directory together, though that might seems too unorganized, commands like
>> `ls` could be modified to sort and/or color-code them according to type, so
>> it's not that big a deal. My only concern doing it that way would be
>> partitioning schemes. You couldn't just mount `users` to /dev/sda1` for
>> instance --but maybe that's not that big a deal since one could create
>> something like /system/partions/users -> /dev/sda1 and then symlink
>> /system/partitions/users/{name} for all /{name} fairly easy.
>>
>>
>
> I don't really like the partitions/users/{name} for all /{name}
> symlinking. I'm just imagining a system with 100+ users. I'm not really
> sure I understand. Why How does adding /groups/ prevent me from mounting
> sdaX to /users/ ?
>

True. One would want to run a script to link it all up, certainly no one
with a 100+ users would want to do it by hand. It's not adding /groups/
that prevents it. I was just saying its a design choice. The layout could
be:

    /users/
      foo/
    /groups/
      bar/

Or just:

    /foo/
    /bar/

I think instinctively the first choice is the one to prefer, but I wonder
if the second might not be better, b/c what really separates a user, a
group and a vendor org? There's not really a hell of lot of difference
between them. For instance, what prevents a user or group from acting as a
vendor? And while on my machine, for example, apache.org/ might just be a
vendor org, on a machine over at apache.org, it would be a group. I'm not
sure it is necessary to require that there be both an /org/apach.org/ and a
/groups/apache.org/. Is there?


> I don't like Nix hashes in directory names, but that's primarily because
> it would seem to make things less intuitive to navigate. My opinion on the
> system would be, avoid them if at all possible, but include them if
> completely necessary. It's really a design decision that needs to be
> thought through well from the beginning.
>

I agree from a admin standpoint they are an eye-sore. But they are also
very powerful. Think in terms of the Conary package system. Using hashes
would allow for a server to cache builds and server them to client machines
per their specific configurations. It would also allow hosts with the same
configurations to share software rather then keeping two separate copies.
Of course that can be done today, but one has to take pains to ensure the
two hosts are compatible (e.g. via a shared usr/ over the network). To
mitigate the ugliness I was thinking of laying it out something like:

  foo.org/
    fooapp/
      1.0.0/
        x86_64/
          451f-8140-c554-324a/
            055b-c164-056b-f759-269c/
              ...

The first hash would represent configuration options and the second the
dependency tree of the package.

I said use Debian packages, but Liam says not to use deb packages. To my
> knowledge this statement is not really true "The .deb format assumes that
> stuff goes in all the usual Unixy places". It is the contents of deb
> packages that determines where things go. I've created deb packages before,
> and they install to the locations I tell them.
>
> Now I think the issue really is, packages crossing distros. I think Liam
> was thinking about using packages for Debian on a Gobo type system. So
> there I could definitely see potential problems If the system cannot
> properly handle a normal Linux program install, then a special package
> format would be better. My question then would be, why can't the system
> handle a normal Linux install? Is it a problem with the symbolic links?
> Does Gobo have this problem? I was under the impression that Gobo could
> handle these things.
>

It's not the file install itself I am worried most about, although there
may be some issues there too. I am more worried about things like pre and
post install scripts (are they called triggers in dpkg parlance?) which
might make assumptions about the system that fits Debian, but not Gobo/Goto.


>
> If deb format was used, I think that anything concerning "problematic
> packages" would be something not to worry to much about. For example, let's
> say an Opensuse user tries to install an rpm made for Fedora. If it works,
> then great! If it doesn't, then they shouldn't be very surprised.
>
> The point is, not everything is going to be compatible, but when they are,
> then that benefits everyone. Allowing packages to install from another
> distro, there is nothing to lose and everything to gain.
>

I think that's perfectly acceptable. I don't see any reason not to allow it
in the same vein as System/Aliens. But as far as the "official" package
manager I want to have something that is designed in the same spirit as the
distro itself. Not just "because", but also in order to improve the state
of the art, which I truly think can be done on a number of counts: use
nix-like hashes, objectroot's vendors/org hiearchy, gobo's cleaner layout
and use of scripting language instead of C. I think all those add up to a
very compelling system. Even so, anyone is welcome to work out a way to
"Alien" install .debs, .rpms or their own variations of any other system
out there.

I do wonder about 0install though. I haven't had a chance to try it yet but
from what I've read, in most respects it seems to cover all the bases I
mention above. Hell maybe its all we really need? But that you don't hear
too much about it worries me. Maybe it doesn't work so well? Does anyone
have knowledge/experience with 0install that can shed some light on it?


> I do agree completely with Liam about using apt. Very familiar interface.
> Very nice system. No matter what package format, having Apt is a good idea.
>

Its worth considering for sure. I just have no knowledge of how to make
that work.


> As last note, I agree with everything concerning the preference of
> scripting languages.
>

That's good to hear! Personally, I think it will proved to be one of the
more compelling features.

    trans.

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