Potential ideas for arguments:
--install-dir=DIRECTORY - change install destination to DIRECTORY
-v | --verbose - enable verbose output for debugging
--target-disk=DEVICE - set the target disk to DEVICE for unattended installations (will erase entire disk)
--include=SOFTWARE - used in conjunction with the tasksel re-implementation, will also install specified software
--root-pw=PASSWORD - the password to use for the root account (entered in plain text)
--no-root-pw - do not set the root password
--username=USERNAME - create the user account with name USERNAME
--user-pw=PASSWORD - password for user account in plain text
--boot-mode=(legacy|uefi) - set the boot mode for the new installation
--hostname=HOSTNAME - set the host name for the installed system
-a | --automate - perform a fully automated install
--version=VERSION_ID - install version with specified ID as opposed to auto-detecting
-e | --expert-install - expert install; perform certain tasks in any order

To prepare for the upcoming release of Debtoo 2.0, debtoo-install and debtoo-dist-upgrade should pull the release list from an external location as opposed to keeping it locally. This way the branch is always determined by the most up-to-date release list.

Which script(s) would this feature belong in?
debtoo-install and update-debtoo

Additional context
For debtoo-scripts v1.2.0, I'd like to add support for multiple branches of a distro. I'm planning to add multiple branches into Debtoo, which include the primary one (unstable), based on Devuan Ceres; testing, based on the testing release of Devuan; and stable, based on the latest stable release of Devuan (which is Chimera as of now). The stable branch will probably require the implementation of a new script, which will probably be named debtoo-dist-upgrade.

Which script would this feature belong in?
update-debtoo

Is your feature request related to a problem? Please describe.
It's possible that when a server is breached, malicious packages could be uploaded to them. This may cause problems for users of the script, so all download source packages should be verified to confirm integrity.

Describe the solution you'd like
Check the SHA-256 hash of downloaded packages, and if they don't match the expected result, stop the upgrade.

To prevent conflicts with other system applications, the prompt which handles creating a user should not allow the username to usernames reserved by the system or certain applications. There is no check which handles this, though, and could lead to problems in the installed system.

For several months now, most input errors cause the script to exit. This was a temporary solution to a bug which caused the script to skip ahead even after an input error until I found a more permanent fix for it. Now I have found the permanent fix, which involves this example:

# sample function
# if the function returns execution code 1, keep trying until it is 0
user_passwd || \
  until [ $? -eq 0 ]; do
    user_passwd
  done

This fix should be implemented in v1.2.2.

Which script does this bug occur in? (apt-source-install, debtoo-install, or update-debtoo)
update-debtoo

Describe the bug
The mirror that the script downloads from is not hosting sysvinit 3.05, resulting in an HTTP 404 error when attempting to download.

To Reproduce
Steps to reproduce the behavior:
Run update-debtoo as shown:
sudo update-debtoo --source-only --no-compile --force-downgrade
When it attempts to untar sysvinit 3.05, it ends in an error:
tar: This does not look like a tar archive

Expected behavior
The script would download and untar sysvinit as normal without any errors.

Desktop (please complete the following information):

• Distro: Debtoo
• Version: Unstable (Flandre)

Additional context
To fix: Change the mirror

Eventually I'd like to add multi-language support if there is enough demand. I don't have anyone I know of to help me translate, though, so this will be put off until we have some translators.

A new script may be added to the repository in the form of a re-implementation of tasksel. The main reason to do this is to avoid downloading packages that conflict with existing source packages. For example, the vanilla implementation of tasksel will attempt to install sudo (binary) when installing a DE, which leads to a conflict over files already installed by the sudo source package. This conflict leads to a softlock, as tasksel does not run apt interactively. The re-implementation will run entirely on the console and allow user input should any conflicts arise.