------------------------
- Initial release.
- Sync functionality doesn't yet exist (pmaint script will be in 0.2)
- pmerge vdb modification requires --force; this will be disabled in 0.2,
mainly is in place so that folks who are just looking, don't inadvertantly
trigger an actual modification.
- not all portage FEATURES are implemented; same for QA.
- If overlays are in use, pkgcore may defer to its' seperate cache to avoid
pkgcore causing cache regen for portage (and vice versa); this occurs due
to pkgcore treating overlays as their own repo and combining them at a
higher level; portage smushes them all together thus rendering each subtree
unusable in any standalone fashion.
- pkgcore is far more anal about blocking bad behaviour in ebuilds during
metadata regeneration; tree is clean, but if you do something wrong in
global scope, it *will* catch it and block it.
- EBD; daemonized ebuild.sh processing (effectively), pkgcore reuses old
ebuild.sh processes to avoid bash startup, speeding regen up by roughly
2x.
Release process
---------------
. Add new entry in NEWS.rst along with changelog updates for the release.
. Make sure dependency versions are correct in requirements/install.txt. Also,
if requirements/pyproject.toml exists make sure dependency versions match
those in requirements/install.txt for matching dependencies.
. Run a test release build by force pushing to a temporary "deploy" branch.
This triggers the release workflow to run on Github, but doesn't actually
upload any of the generated files to PyPI or Github.
. Verify the test build looks correct and passes tests then tag the new
release and push the tag. If everything works as expected, both PyPI and
Github should automatically get the release files pushed to them once the
action completes.
. At this point, it's good to remove the temporary deploy branch from the
upstream repo.
. Make a commit bumping the package version via __version__ in the base module
and push the commit.