Xterm shows in 3.10

I noticed (as I do) that xterm and uxterm now show up in the launcher (they don’t in 3.9). I would say that the xterm package could just be removed but it seems some Endless packages depend on it namely:
eos-core eos-core-amd64 eos-factory-tools

While thinking about packages to remove…
ifupdown - networkmanager should really cover this
ntp - at least the default config could be handled easily by the systemd-timesyncd (although I see it’s been removed)

Thanks for your input here! xterm is still used by some factory-support tools we have, so it is staying around at least for now, but we are looking at ways to exclude it’s desktop icon like we did before.

ifupdown is priority important, like rsyslog & logrotate, not planning to take action against that at this time… but would welcome a Debian-upstream discussion on them changing this!

We should probably re-examine migrating ntp to systemd-timesyncd as you suggest… When we looked before (years ago) it did not work as well as ntp for the case where you are not using systemd-networkd for networking.

Will look into the Debian end about those not being priority important.

I’d also be happy to see if they could be removed from the image (or not included) - is there a more recent way to build an endless OS like image then https://github.com/dbnicholson/deb-ostree-builder ? (that’s what ostree repo links to)

My quick check (XFCE builds) seems to indicate that debian11 defaults to using systemd-timesyncd. Will check again with a fresh build.

If using debootstrap doing --variant=minbase would just exclude all “important” packages and just install the required set.

Yes a minimal debian bullseye image used systemd-timesyncd. Oddly enough it does not include dbus which means querying using timedatectl doesn’t work with a bus error.

It’s too late to look at changing important level packages for bullseye - will look into it for 12.

We use mmdebstrap but there is probably a similar option there.

We are in the process of opening up our tools etc, but we’re still some distance away from publishing the ostree builder. However, we are trying to align with Debian as much as possible, so we might not take any kind of whitelist or blocklist approach even if its quite simple to achieve, unless there’s some tangible link to achieving our mission of increasing access to technology & education.

But there may be an interesting angle of can we drop the installation of all Priority important packages? as you suggest. Would this cause some important stuff to be dropped? I would imagine so, but I admit to not having checked, I’m also not familiar with the guidelines/policy around how Debian tags packages like this.

Indeed mmdebstrap does have equivalent --variant options.

I generated two examples and the default here. Anything that really is required should be a dependency that gets brought in anyway. Checked systemd and dmidecode and I believe they would both be brought in by existing depends. isc-dhcp-client may not be brought in, so that could be an issue - although easily added to one of the meta packages.

Aside: It seems like the Priority field might be getting changes at some point: https://wiki.debian.org/Teams/Dpkg/Spec/ProtectedField

Interesting - indeed my rough understanding was not quite right, perhaps it is not really necessary to preinstall all Priority important packages in the general case. When we have a chance we should experiment with the --variant option and seeing if any truly interesting packages do get dropped.

@dan FYI!

Indeed! Thanks @BryanQuigley for the lists! I hadn’t looked at this in a while.

Installing Priority: Important goes back to the beginning of Endless likely because that’s the default that debootstrap does. However, we did discuss this around roughly 2017. It really just needs someone to analyze what’s there, determine what we want, and ensure it’s in our own metapackage. Just like when we dropped Recommends and you put together a system to make sure we acknowledged what was in there.

You definitely don’t need the important packages to boot. They’re a bit more like Recommends in the sense that they’re things you’d probably expect to be installed. Like, can you boot without udev and systemd? Sure, but that’s definitely not the experience we’re going for in Endless.

BTW, here’s how you can get the same info straight from the apt lists using dctrl-tools:

$ grep-aptavail -n -s Package -F Essential yes
$ grep-aptavail -n -s Package -F Priority required
$ grep-aptavail -n -s Package -F Priority important

I never knew about grep-aptavail - thanks!

Went through all the packages and this is what I found:
In eos-meta explicitly
apt-utils debconf-i18n debian-archive-keyring gpgv iproute2 kmod less netbase whiptail systemd-sysv udev vim-tiny

Brought in by something else:
adduser cpio dmidecode procps libreadline8 readline-common sensible-utils systemd fdisk

Add to eos metapackages IMHO:

Need discussion?
isc-dhcp-client (Network Manager has a built-in one that I just switched over too… Seems fine…).

To be removed:
cron ifupdown logrotate rsyslog tasksel-data init (explicitly depending on systemd makes more sense)

Happy to make the PR if the above looks sane. I’d plan to add the isc-dhcp as that seems like a bigger change.

Sounds good to me, I would be willing to give this a try based on what you have found here.

I see in my logs:
NetworkManager[375]: <info> [1616464740.4540] dhcp-init: Using DHCP client 'internal'
Looks like this is the NM default. So isc-dhcp-client can be removed too, it is not being used.