Move CLI under desktop

[igorpecovnik]

Perhaps it would be wise to have the same logic that we don't have different styles for CLI and desktop?

• rename config/desktop -> config/packages or similar
• only leave debootstrap in configuration.sh
• CLI config_full = current stable config_minimal = minimal image
• name CLI package base as "core" or similar

What do you think?

[igorpecovnik]

... or probably just move under config/cli and have the same org and its perhaps a bit more logical?

[Miouyouyou]

Hmm... ? So, you want package groups for command line tools ? like config/cli/focal/appgroups ? But named config/cli/focal/environments/default ?

With something like :

• config/cli/focal/environments/default/config_minimal/packages
  bc cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server nocache debconf-utils python3-apt network-manager wireless-tools lsof htop mmc-utils wget nano sysstat net-tools resolvconf iozone3 jq libcrack2 cracklib-runtime curl
• config/cli/focal/environments/default/config_full/packages
  bc cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server nocache debconf-utils python3-apt network-manager wireless-tools lsof htop mmc-utils wget nano sysstat net-tools resolvconf iozone3 jq libcrack2 cracklib-runtime curl bridge-utils build-essential fbset iw wpasupplicant sudo linux-base crda wireless-regdb unattended-upgrades console-setup unicode-data initramfs-tools ca-certificates expect iptables automake html2text bison flex libwrap0-dev libssl-dev libnl-3-dev libnl-genl-3-dev keyboard-configuration software-properties-common alsa-utils btrfs-progs dosfstools iotop stress screen ntfs-3g vim pciutils evtest pv libfuse2 libdigest-sha-perl libproc-processtable-perl aptitude dnsutils f3 haveged hdparm rfkill vlan bash-completion hostapd git ethtool unzip ifenslave libpam-systemd iperf3 libnss-myhostname f2fs-tools avahi-autoipd iputils-arping qrencode sunxi-tools

And have the build system aggregate these packages list and install them like the rest ?
I haven't played too much with CLI configurations, so I don't know what people would expect from a CLI only configuration. I guess that environments does the trick in this case ?

[igorpecovnik]

I guess that environments does the trick in this case ?

Yes, I think this way. This is more or less a thinking - not sure if we want this but we also have to make sure that:

• this will not bring more complication
• that this new system can covers all exceptions used in current config
• will remove the need of this section https://github.com/armbian/build/blob/master/lib/configuration.sh#L197 (i think it does)
• this https://github.com/armbian/build/blob/master/lib/configuration.sh#L140 is unchanged base, also possible that we move more common things there, perhaps later. Now we better transfer the exact same base so we could compare results of old and new build
• what to do with overrirde https://github.com/armbian/build/blob/master/lib/configuration.sh#L304
• and packages remove https://github.com/armbian/build/blob/master/lib/configuration.sh#L308 (do we have this in the system like "packages_remove" where we remove some package - which are installed with some meta packages but we don't want them - at the end

[Miouyouyou]

I'm okay with most of the points.

• The big case switch in configuration.sh mainly targets debootstrap packages list. I could provide the same mechanism for deboostrap packages, that way we could eliminate the whole case switch.
  So basically add something likeconfig/cli/focal/debootstrap/packages.list.
  However, we'd still need a way to provide the debootstrap components list. Something like config/cli/focal/debootstrap/components containing a comma-separated list of components ?
• The line in https://github.com/armbian/build/blob/master/lib/configuration.sh#L304

[[ $BUILD_DESKTOP == yes ]] && PACKAGE_LIST="$PACKAGE_LIST $PACKAGE_LIST_DESKTOP $PACKAGE_LIST_DESKTOP_RECOMMENDS"

is now equivalent to [[ $BUILD_DESKTOP == yes ]] && PACKAGE_LIST="$PACKAGE_LIST $PACKAGE_LIST_DESKTOP" since I removed the PACKAGE_LIST_DESKTOP_RECOMMENDS when implementing my system.
The line before is just an aggregation of the package lists defined manually, but I don't think that this aggregation would still be relevant when using a config_* based system, like the one currently used for Desktop environments.

• The packages removal is not implemented for the moment. I can easily add support for a packages.remove list... However, is this functionality actually used ?
  I'm searching for "lib.config" files but I can't seem to find any. And I don't know what could fill that PACKAGE_LIST_RM variable. Grep'ing for PACKAGE_LIST_RM just lead me the linked section.

So I'll just try to implement the "cli" packages system by mimicking the way it's done for Desktop environments, removing as much cruft as possible and give it a try with Tinkerboard (armv7) and NanoPCT4 (arm64) builds, see how it goes.

[igorpecovnik]

containing a comma-separated list of components ?

Perhaps have the same structure without coma in the config and comma programmably? Deboostrap needs commas there for some reason, otherwise I don't know why we have that. Anyway, this is not changing and its more on the cosmetic side of the problem.

We have to support package overrired / adding and removing as it is now. There are people that are using this feature.

I'm searching for "lib.config" files but I can't seem to find any.

Located in userpatches/lib.config and its optional - its there to overrire any variable that is used in the process. I use it to define proxy or image type:

COMPRESS_OUTPUTIMAGE="sha,gpg,xz"
APT_PROXY_ADDR="10.0.10.10:3142"

Something that is common to all build config files. Also here one could overrire aggregated packages for some reason or overrired U-BOOT version without the need to dig into the code.

The packages removal is not implemented for the moment. I can easily add support for a packages.remove list... However, is this functionality actually used ?

Not by us, but its used by some people to get rid of certain default components when making a custom image. Like minimal image, but remove Python for example.

[Miouyouyou]

So I started to implement some features in another branch https://github.com/Miouyouyou/armbian-desktop/tree/cli_packages .
Do you have a lib.config example file I could use, to test if this is working correctly ?

I was wondering if I should add a 'packages.remove' file or just support the old lib.config way, but since this feature is mostly used by third-parties, retro-compatibility is required, so I'd like to keep the lib.config way.

[igorpecovnik]

APT_PROXY_ADDR="10.0.10.10:3142"
FORCE_USE_RAMDISK="yes"
COMPRESS_OUTPUTIMAGE="7z"

I was wondering if I should add a 'packages.remove' file or just support the old lib.config way, but since this feature is mostly used by third-parties, retro-compatibility is required, so I'd like to keep the lib.config way.

Can we have both and retro beeing a last override? Will tha complicate things?

For example. We always want to remove "ubuntu-wallpaper" which is soft dependency ... while user will want to remove even more. Better or too complicated?

[Miouyouyou]

Oh, yeah, lib.config contains actual variables that are sourced in configuration.sh in order to override what's provided on the command line, alright. Took time some time to tilt.

I think I should be able to mix both, that should be pretty easy to add.