... | ... | @@ -3,18 +3,18 @@ |
|
|
|
|
|
## General Goals
|
|
|
|
|
|
* `apkg` should make it easy to package software for various distributions directly from upstream.
|
|
|
`apkg` should make it easy to package software for various distributions directly from upstream.
|
|
|
|
|
|
* `apkg` must be pleasant to use from interactive terminal sessions, shell scripts, python scripts (as a module), and in CI systems.
|
|
|
`apkg` must be pleasant to use from interactive terminal sessions, shell scripts, python scripts (as a module), and in CI systems.
|
|
|
|
|
|
* `apkg` should be smart and infer as much information from environment as possible in order to require no or little parameters to perform its duties. This must be transparent and still allow fine control. If human can do it, machine can too.
|
|
|
`apkg` should be smart and infer as much information from environment as possible in order to require no or little parameters to perform its duties. This must be transparent and still allow fine control. If human can do it, machine can too.
|
|
|
|
|
|
|
|
|
## Convetions
|
|
|
|
|
|
* `apkg` is to be invoked in a local `git` copy of a project to be packaged.
|
|
|
`apkg` is to be invoked in a local `git` copy of a project to be packaged.
|
|
|
|
|
|
* `apkg` operates on a current `git` commit. Behavior might differ between commits with and without version tag (such as `v1.0.0`) but operation and outputs must be consistent from user point of view and always carried out in context of currently checked-out git commit by default.
|
|
|
`apkg` operates on a current `git` commit. Behavior might differ between commits with and without version tag (such as `v1.0.0`) but operation and outputs must be consistent from user point of view and always carried out in context of currently checked-out git commit by default.
|
|
|
|
|
|
|
|
|
### Input
|
... | ... | @@ -46,19 +46,18 @@ This has few advantages over individual packaging directories directly in root a |
|
|
|
|
|
Optional `.apkg.conf` configuration file might be introduced to allow customization for non-standard setups.
|
|
|
|
|
|
**TODO**:
|
|
|
* carefully consider name for top level packaging directory (now `distro`)
|
|
|
**TODO**: carefully consider name for top level packaging directory (now `distro`)
|
|
|
|
|
|
|
|
|
### Output
|
|
|
|
|
|
* Any successful `apkg` operation MUST result in a clean git repository.
|
|
|
Any successful `apkg` operation MUST result in a clean git repository.
|
|
|
|
|
|
* Operations that modify project source (for example files in `distro/`) MUST create appropriate and well-named commit, inform user about creation of new commit (for example by showing `diff`), and result in clean `git` (when they succeed). That way, user can easily view what `apkg` did using `git show` and/or undo by `git reset --hard HEAD~` when unhappy with results.
|
|
|
Operations that modify project source (for example files in `distro/`) MUST create appropriate and well-named commit, inform user about creation of new commit (for example by showing `diff`), and result in clean `git` (when they succeed). That way, user can easily view what `apkg` did using `git show` and/or undo by `git reset --hard HEAD~` when unhappy with results.
|
|
|
|
|
|
* Operations that generate files shouldn't spam project root - create a few well-named output directories and put files there.
|
|
|
Operations that generate files shouldn't spam project root - create a few well-named output directories and put files there.
|
|
|
|
|
|
* When generating distro-specific files, mirror the respective layout of `distro/` sub-directories when viable, for example:
|
|
|
When generating distro-specific files, mirror the respective layout of `distro/` sub-directories when viable, for example:
|
|
|
|
|
|
```
|
|
|
project
|
... | ... | |