Improved desc. in README, explain why tool exists

Barely anything has changed, but the package *is* different. v3 is from
months back and is missing information that Crates.io kinda wants.

Cargo.toml

@@ -1,23 +1,18 @@
 [package]
 name = "gt-tool"
-version = "3.0.0"
+version = "3.0.1"
 edition = "2024"
+license = "GPL-3.0-only"
+description = "CLI tools for interacting with the Gitea API. Mainly for attaching files to releases."
+# homepage = "" I have no website for a project home page :(
+repository = "https://git.gelvin.dev/robert/gt-tool"
+readme = "README.md"
 
 [dependencies]
-clap = { version = "4.0.7", features = ["derive", "env"] }
-colored = "2.0.0"
-itertools = "0.10.0"
-reqwest = { version = "0.11.13", features = ["json", "stream", "multipart"] }
-serde = { version = "1.0.152", features = ["derive"] }
-tokio = { version = "1.24.2", features = ["macros", "rt-multi-thread"] }
-toml = "0.5"
-
-# Packages available in Debian (Sid)
-# clap = "4.5.23"
-# reqwest = "0.12.15"
-# tokio = "1.43.1"
-
-# Debian (Bookworm)
-# clap = "4.0.32"
-# reqwest = "0.11.13"
-# tokio = "1.24.2"
+clap = { version = "4.5.23", features = ["derive", "env"] }
+colored = "2.2.0"
+itertools = "0.13.0"
+reqwest = { version = "0.12.15", features = ["json", "stream", "multipart"] }
+serde = { version = "1.0.217", features = ["derive"] }
+tokio = { version = "1.43.1", features = ["macros", "rt-multi-thread"] }
+toml = "0.8.19"

README.md

@@ -1,6 +1,12 @@
 # gt-tool
 
-CLI tools for interacting with the Gitea API. Use interactively to talk to your Gitea instance, or automatically via a CI/CD pipeline.
+A CLI tool for interacting with the Gitea API. List existing releases, create new ones, and attach release-items (files) to them. It can be used interactively as one publishes their work, or automatically as part of a CI/CD pipeline.
+
+## Why this thing exists
+
+This program exists because I find GitHub Actions to be an insufficient system. There is no official "release-attachment" workflow. I have to either make my own or find someone else's. Since there is no standard Workflow for this task, the [Gitea version](https://gitea.com/actions/gitea-release-action) has a different API. Since I can only use branches, tags, or exact commit hashes, my dependency resolution is often manual or happens in surprising ways (e.g.: force pushing a new version tag). Adjacent to this is the issue that lots of dependencies are "assumed" and cannot be named -- like how the Ubuntu base image contains NodeJS, even if I never ask to install it. Finally, I can't easily execute or re-execute the workflows. There is no "run Action" button and I can't run any of it from my dev machine.
+
+So I figured I'll make my own as a learning exercise and try to address as many of those problems as I can. The key is recognizing that a CI/CD platform needs a package manager. I like Debian, so I will stand on its package manager, although it might be better to pick NixOS or Gentoo. A GH Workflow which depends on this tool needs only to record it's name -- declarative build dependencies! This feature extends to the entire Debian container, automatically giving me full-system dependency knowledge. Updating the build environment is exactly like updating a normal Linux host because it *is* a normal Linux host. Lastly, it's also *a normal CLI program* so you can use it from your own dev workstation. There is no need for a "run Action" button.
 
 ## Usage