I just read the review (https://distrowatch.com/weekly.php?issue=20170123#gobo) of GoboLinux on DistroWatch and I stumbled upon something interesting. Gobo rearranges the classic unix file structure to a more humanreadable format and organization. (It was also mentioned in the nixers podcast about the unix file structure)
Anyways, in the review, they mentioned Gobos applications are contained in a single directory. If you want to uninstall an application, you can just delete the directory. Could one use this as a replacement for traditional package-management? You would just need some kind of dependency resolution, but all the tracking of files could be avoided through the intelligent file structure design.
I really like the idea of installing packages just with make and delete them with rm. Feels really unix-y for me.
Opinions, corrections or something else?

That looks really neat. It appears the Application folders have dependencies listed in them. Does it have a package manager? I may spin it up in a VM. Definitely very interested in this project. Would be interesting to make a tool to convert .deb packages into app folders on this distro.

When I see Gobolinux's "/Programs", all I can think of is "C:\Program Files", which is roughly the same: an "app directory" containing all he bits to make a program works. It even contains all its external dependencies ("containers", yikes).

Gobolinux get one point right though, the separation of directories makes no sense in the present context. I'm pretty confident that 500Mb can fit on a signle parition! Don't call me fool here!! It's the future!!

This distro also impresses me by the cleanness of its file tree. I've been working on a distro myself, and getting programs to install elsewhere than /usr or /usr/local can be a real pain sometimes (especially when it comes to the toolchain!). The idea of using overlayfs to "put back" programs in the original tree is pretty awesome, and allow for many possibilities (eg, ls /Programs/Executables to see all your binaries for example).

In the end, Gobolinux is an impressive distro to me. It's not one I would use myself for different reasons that are only relevant to me, but I'm really respectful of the work done here. And if anyone has anything to say against Gobo, I suggest they read this page first: https://gobolinux.org/doc/articles/clueless.html

(24-01-2017, 11:02 PM)hades Wrote: Does it have a package manager?

According to the review, it does, but it doesn't have a lot of packages and no ports system, so have you have to compile packages for yourself.

(25-01-2017, 04:41 AM)z3bra Wrote: When I see Gobolinux's "/Programs", all I can think of is "C:\Program Files"

Except, when you delete a folder in Windows the application is everything else than uninstalled. That's definitely an advantage of GoboLinux' approach.

Reading both your opinions, I tend to think of '/Programs' more like a concept similar to flatpak/snap without the sandboxing, because the applications get their own dependencies, kind of their own runtime. Although, it doesn't provide support to other distributions... Maybe it's just it's own thing, not that easily comparable with other concepts.

I like the GoboLinux way too. This takes part of the UNIX-style tree with a solution for some of its drawbacks, as isolation of programs.

On the other hand, if I had to do the same, I would not make an additionnal Index directory, and make the lists straight in the root directories.

(25-01-2017, 04:41 AM)z3bra Wrote: getting programs to install elsewhere than /usr or /usr/local can be a real pain sometimes

From http://sta.li/filesystem

(25-01-2017, 07:43 AM)asyncial Wrote: According to the review, it does, but it doesn't have a lot of packages and no ports system, so have you have to compile packages for yourself.

Recently, there is a build system to install .deb and .rpm packages, and tools to build packages from source too.

---

I decided to try on Arch linux:

- I ran a busybox shell with <code>busybox sh</code>;

- I moved all the content of <code>/usr</code> to <code>/</code>

- I symlinked <code>/ -> /usr</code>

- I rebooted and everything went fine:


[EDIT] and then I ran pacman and then <code style="color: #990000;">rain of segfaults</code> and I have to reinstall... Not a bad experience, though.

---

I made a package manager in the style of Gobolinux, but using ~/programs and ~/.local instead of /Programs and /System/Index.

(25-01-2017, 03:34 PM)josuah Wrote: I like the GoboLinux way too. This takes part of the UNIX-style tree with a solution for some of its drawbacks, as isolation of programs.

On the other hand, if I had to do the same, I would not make an additionnal Index directory, and make the lists straight in the root directories.

(25-01-2017, 04:41 AM)z3bra Wrote: getting programs to install elsewhere than /usr or /usr/local can be a real pain sometimes

From http://sta.li/filesystem

I'm aware of stali's filesystem, and mostly agree that it's a good one. But if you take a close look at it, stali doesn't have gcc, binutils, or anything toolchain related (and I definitely understand why).

In fact MANY MANY MANY programs build recipes include hardcoded path, like ${PREFIX}/share/man, like ${DESTDIR}/lib64, or attrocities like

That simply preventing you from installing directly to / at all. Many hacks exists, like the famous "ln -s . /usr", but one shouldn't have to do this.

(25-01-2017, 07:43 AM)asyncial Wrote: According to the review, it does, but it doesn't have a lot of packages and no ports system, so have you have to compile packages for yourself.

This is a port-like system that you can retrieve it locally to compile softwares for your own system.

(25-01-2017, 03:34 PM)josuah Wrote: I decided to try on Arch linux:

- I ran a busybox shell with <code>busybox sh</code>;
- I moved all the content of <code>/usr</code> to <code>/</code>
- I symlinked <code>/ -> /usr</code>
- I rebooted and everything went fine:

[EDIT] and then I ran pacman and then <code style="color: #990000;">rain of segfaults</code> and I have to reinstall... Not a bad experience, though.

I must say I love and hate arch at the same time. They figured there was a problem: "Hey, installing binaries in 4 different locations is totally stupid!". And they solved it with the most stupid way they could think of: making /usr their REAL /.

I mean, seriously?

(25-01-2017, 03:34 PM)josuah Wrote: I made a package manager in the style of Gobolinux, but using ~/programs and ~/.local instead of /Programs and /System/Index.

Sound fun! I like that you managed to keep the recipes as small as possible, making it easy to create new recipes.

There is no version checking, making it impossible to update your packages in bulk, but this is an interresting choice IMO, as it makes the whole script way simpler both for the code and the usage.
I would have put the "broken symlink" management in the remove() function though, as that's technically the only moment where symlinks will be broken (unless I missed something).
Also, I'm curious as to if all your exported variables are actually used. For example, if you install "libncurse" and then compile "vi" statically against it, will it effectively use your "local" ncurse, or the system-wide one?

(26-01-2017, 08:11 AM)z3bra Wrote: or anything toolchain related

I never remarked this. Maybe they were put in /suck

There is no version nor dependency checking, as I use it along with another distro-provided package manager. Both complementing each other.

Yes, thank you that makes sense, broken link in remove().

One need to source the script itself from .profile to get all PATH, LD_RUN_PATH & co. set. During compilation, this does not always work very well, I still have to figure out how to reliably do this.

For stali, the distro simply isn't self-hosted,to which means it cannot recompile itself OOTB.

e most reliable way I could find is to use a cross-compiler for this.

Looking back at this thread it seems to resonate a lot with the newer trend towards static builds and/or reproducible build and/or universal package managers. All package management solutions trying to tackle the same issue.
As far as this thread goes we're concerned with, what do you think of the idea of using a different hierarchy while also mixing it with a package manager that respects it.

> what do you think of the idea of using a different hierarchy while also mixing it with a package manager that respects it.

I think that's a great way to compromise to get what you need, /now/. As a NixOS user, it's great when it works, but then it doesn't, sometimes you end up poking for quite awhile to get things wrapped (binary releases, games, propietary tools, ...). In the long haul I'm here for it, but it can be annoying if you need something localy native when your brain is in "monke mode".

Of course, with containers we can always cheat. docker-as-service-manager is always an out.