Why so strange and wide dependencies for simple Git?

Twinpigs

Thank You. So gitk and git-gui should depends on Tk, not Git itself.
The same case issued with PHP. I can't just install php-cli to provide interpreter for IDE because it depends on whole web-server.

DataDrake

Twinpigs So gitk and git-gui should depends on Tk, not Git itself.

Wat. That's not how dependencies work in any universe.

gitk -> {git, tk}
git-gui -> {git, tk}

Except that in Solus we don't split packages just because people expect us to. tk is a few megabytes. All of the perl deps combined are less than that.

Twinpigs The same case issued with PHP. I can't just install php-cli to provide interpreter for IDE because it depends on whole web-server.

Same thing goes for php. We aren't going to split it just because it depends on postgres...which isn't a web server. It's a database engine. And a whopping 16MB at that 😛

Total nothing burger. If you are looking for a hyper-minimal install, this is the wrong distro for you.

prateekmedia

DataDrake Maybe sol could solve it 😃

Twinpigs

DataDrake gitk -> {git, tk}
git-gui -> {git, tk}

I don't realize. Ok, let gitk and git-gui depend on git AND tk. But git still doesn't depend on tk, right? Wat's wrong with my universe where I never use gitk and git-gui?

DataDrake

prateekmedia No. This isn't a limitation of eopkg. It never has been. Solus intentionally avoids optional dependencies and over-splitting packages. Optional dependencies have poor discoverability in general and aren't something I would ever personally endorse. Over-splitting increases the time and/or difficulty of package maintenance, and often for very minimal actual benefit. Especially on modern systems where Solus can take up 20-40GB without really affecting available space. Compare this with how minimal our base install actually is, and you'll see that it's just not worth it. We can and do split packages, even difficult ones like texlive, but it needs to serve a purpose other than just saving a little disk space. If we were talking 10s or 100s of deps, that might be reasonable. But this really is a mountain of a mole-hill.

DataDrake

Twinpigs What's wrong is that they they aren't actually different packages: the source tarball for git and gitk and git-gui are all one single archive. When we package git for Solus it's up to us to manually move files into separate installable archives. That process is known as "splitting" and we don't do this without a compelling reason. Most distros split up packages significantly more than we do. But this has several side-effects that we don't agree with philosophically in Solus:

Splitting packages increases maintenance burden. In other words, the maintainers need to do more work for every subsequent update to ensure that all of the right files get put in the correct archives, that each combination of installed archives works, etc. This means more time needs to be spent on each package and more maintainers need to be found. At present we have between 10-20 regular contributors to Solus, including the Solus Team (Core + Globals) itself. We don't have an army of maintainers like other distros to take up this extra work.
Splitting packages reduces discoverability. When you split up a package, it isn't always obvious what files belong to which archive. Each archive can have a separate descriptions to help with this, but it's not bullet-proof. People still have to be able to find what they are looking for which is a lot easier when it's as few archives as necessary.
Splitting packages isn't standardized. Every distro splits their packages differently. This causes significant confusion when people switch between distros or writing guides that are trying to be distro-agnostic. Solus tries to standardize this process as much as reasonably possible for its own packages. For example, when glibc is built, it is automatically split into six separate packages without maintainer intervention: glibc, glibc-devel, glibc-dbginfo, glibc-32bit, glibc-32bit-devel, and glibc-32bit-dbginfo. This splitting is done using an identical set of rules for all Solus packages and more importantly, it's automated by our package tooling and much easier to test since each sub-package has a specific and identical use based on suffix.

Twinpigs

Now I see. Thank you. Just can't stop thinking about that tons of gigabytes at HDDs through the whole world wasted due to unsplitted once packages.

Junglist

Twinpigs It's hardly tons of space.

I have 1657 eopkg packages installed and 5 flatpaks (my install is near 2 years old). All such a large number of packages takes up, is 28.9 GB (this is the space my root partition takes up, not counting the home directory and my swapfile), and anyone who doesn't install stuff willy-nilly like me, will have a lot less packages installed, so it'll take up even less space.

DataDrake

Twinpigs If you start going down that route, there are plenty of ways distros and software developers "waste" space for convenience, performance, and safety.

Shared Libraries There's no guarantee that every function is used by any or all of the programs installed, even collectively. But by leaving all of those functions in, we avoid compatibility issues, especially with non-packaged software.
Scripting Languages The source code for these programs is often larger than the equivalent binary in a compiled language. But for many, the time spent compiling code during development isn't viewed as productive, which is why they prefer these languages, despite being larger.
Locales Most systems are single-user or shared by users in the same geographic area, so there's really no need to have all of the locales under the sun installed. At the same time, some locales are required as a fallback when translations aren't available. Figuring out which are needed is not a trivial exercise. Asking the package maintainers to figure this out requires a degree of skill they likely don't have or time they are unwilling to dedicate to maintenance.
Verbose File Formats For every kind of data, there exists an optimal binary encoding which takes up as little space as possible. But sometimes you want files to be human-readable, to make development easier or for the end-user. Sometimes you can't justify the time to develop an efficient binary format because you know the data format will change frequently. Either way, these files end up being significantly larger than necessary.
Uncompressed Files There are many files we could at least compress to save disk space, but we don't. Sometimes the time required to compress/decompress is too much for the application. Sometimes compression algorithms are expensive and we want to save battery life. Sometimes users or maintainers need to be able to easily access or modify these files without dealing with compression.
Swap Space Strictly speaking, you don't need swap at all. But when you have it, there are a couple of nice features it brings to the table. First, it allows memory usage to burst passed the maximum RAM for the system. This prevents OOM hard-locks where the system freezes and can't recover. It also allows programs to burst quickly to higher memory usage, without invalidating other cached pages since those pages can be moved to swap temporarily. restoring these pages from swap is almost always faster than having to reload the data from storage.
Log Files Technically speaking, logs are used much less often than not. They are often encoded in inefficient human-readable formats and are rarely configured to be cleaned up at what most people would consider to be a reasonable size. But when you need to figure out what went wrong on a system, there is no substitute.
File Caches Web browsers, package managers, compilers, etc. rely on file caches to speed up their operation and often to reduce their need to use network bandwidth. Strictly speaking, you don't need these files at all for the program to function. It could always fetch or regenerate them. But the cost of that has to be weighed. Having to refetch files from web servers means more network bandwidth, network load, more load on the web servers, and longer page load times. All while exposing your system to even more time connected to remote machines which isn't great for security or privacy. Having to regenerate build artifacts when compiling programs means that compilation takes longer. In both of these cases the user has to wait longer and their machines have to expend more power to do identical operations.

You seem to be thinking of storage space as this finite resource that is lost as soon as it is used. On the contrary, storage is significantly more reclaimable than other resources. It can easily be overwritten with other data. Drives can last for several years without failure, even after be overwritten hundreds of thousands of times. Most of the components in these drives can even be recycled to make other things.

Twinpigs

It was kind of joke of course.

DataDrake

Twinpigs Lol. Well it certainly didn't read as one.

brent

DataDrake On the plus side, I feel like I'm earning an IT degree when I read your responses!

Twinpigs

I gave it another try, but php depends on postgres... OMG, why?! You were right: it's not for me. Sooo sad.

Staudey

Twinpigs Oh no, 18 whole 📣MEGA📣bytes WASTED 🤯 🤯 🤯 🤯 🤯 🤯 🤯