search

bedrocklinux / bedrocklinux-userland

This tracks development for the things such as scripts and (defaults for) config files for Bedrock Linux
https://bedrocklinux.org
GNU General Public License v2.0
603 stars 64 forks source link

(Feature Request) stratum info #173

Closed Titaniumtown closed 4 years ago

Titaniumtown commented 4 years ago

There should be (if there isn't already) a command that returns info about an installed stratum.

What I think such a command should be like:

brl info fedora

Operating system: Fedora
Version: 32
Architecture: x86_64
Space taken up on disk: 10 gb
paradigm commented 4 years ago

Bedrock has survived as long as it has by keeping the project scope something the very limited available developer/maintainer hours can do. In general, Bedrock is about making features from other projects accessible and not about reinventing the wheel where other projects have already done something. Here, it seems like most of what you're looking for is provided by other projects such as neofetch:

$ strat -r fedora neofetch distro
distro: Fedora 32 (Thirty Two) x86_64

I don't know off the top of my head a good way to get disk usage of a stratum, which makes implementing your last field difficult. For specifically disabled strata which are not their own partition, you can query disk usage with du:

$ sudo brl disable fedora
$ sudo du /bedrock/strata/fedora
955M    /bedrock/strata/fedora

Moreover, if Bedrock were to create its own implementation despite the fact it's largely reinventing the wheel, this is going to require maintenance work to follow upstream distro changes, and we're badly hurting for distro maintainer hours as it is.

That having been said, I could be missing something. Do you see a use case for this feature sufficient to overcome the above reasons not to implement it?

Titaniumtown commented 4 years ago

I guess I could write something once #175 is merged

paradigm commented 4 years ago

To be clear, the reasons I listed against are not about the one-time cost of an initial implementation. Even if you write it, if you don't provide a reason for why it should overcome the reasons listed above, it's unlikely to be merged.

If your considering writing something for your personal needs with no interest in upstreaming it, there's no need to wait for #175; you can write a stand-alone utility to do this and drop it in whenever #175 is ready.