search

clearlinux / distribution

Placeholder repository to allow filing of general bugs/issues/etc against the Clear Linux OS for Intel Architecture linux distribution
522 stars 29 forks source link

slim down gnome desktop bundle #423

Closed zlnd closed 5 years ago

zlnd commented 5 years ago

hi! is there any possibility to slim down the gnome desktop bundle? i mean, gnome apps have evolved great and are pretty useful, but many users do not need programs like cheese, or maps, to say some. by my experience not even tracker, evolution and it's services are required for a fully functioning gnome desktop. a barebones option can be helpful for both power users and owners of under powered, low storage machines, etc. maybe removing desktop-apps as a dependency of desktop bundle can do the trick?

otherwise, thanks for your hard work!! really appreciating your os and waiting to see your innovations, optimizations and tweaks on other linux systems!

ahkok commented 5 years ago

Gnome itself dictates what constitutes a minimal desktop and it includes from what I can remember, some of the items you mentioned, like cheese.

For a bare bones option, please consider Xfce4, lightdm or i3 desktops instead, they are far more suitable for smaller installations, and gnome doesn't really approach the small size that some people think is reasonable.

fenrus75 commented 5 years ago

we could mkae a smaller bundle I suppose and have the big one include it.. but to some degree, gnome decides what is gnome, and people tend to get upset if we deviate too much

On Wed, Jan 23, 2019 at 10:44 AM ahkok notifications@github.com wrote:

Gnome itself dictates what constitutes a minimal desktop and it includes from what I can remember, some of the items you mentioned, like cheese.

For a bare bones option, please consider Xfce4, lightdm or i3 desktops instead, they are far more suitable for smaller installations, and gnome doesn't really approach the small size that some people think is reasonable.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clearlinux/clr-bundles/issues/97#issuecomment-456919295, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPeFYgVOKFXF89b4Crgj7K5fxk15cX7ks5vGK19gaJpZM4aNifg .

zlnd commented 5 years ago

hi @fenrus75 , thanks for your response.

@ahkok , i understand that gnome is it's whole ecosystem of apps. i don't want it butchered. i'm just saying that a bundle consisting of a small core of gnome apps would be pretty helpful on some cases. it's not a technical challenge or a disrespect to the gnome devs or anything, just an useful option.

i love gnome. it's modern, well made, and getting better and better in features, design and responsiveness. i think resource restricted users, or users looking for a lightweight installation don't have to be "forced" to use lxqt, xfce or an wm for having an ui.

Gnome itself dictates what constitutes a minimal desktop and it includes from what I can remember, some of the items you mentioned, like cheese.

For a bare bones option, please consider Xfce4, lightdm or i3 desktops instead, they are far more suitable for smaller installations, and gnome doesn't really approach the small size that some people think is reasonable.

eero-t commented 5 years ago

Gnome itself dictates what constitutes a minimal desktop and it includes from what I can remember, some of the items you mentioned, like cheese.

For a bare bones option, please consider Xfce4, lightdm or i3 desktops instead, they are far more suitable for smaller installations, and gnome doesn't really approach the small size that some people think is reasonable.

Obviously this shouldn't be implemented just by removing programs from the bundle, but by splitting it to smaller logically separate bundles, by their functionality and dependencies.

we could mkae a smaller bundle I suppose and have the big one include it.. but to some degree, gnome decides what is gnome, and people tend to get upset if we deviate too much

I think all other distros to split them => not a problem when done properly?

Help in how to best split the Gnome components could be found e.g. by looking at how the other distributions have done it, what kind of meta-packages ("bundles") they've done, what are the hard dependencies and what are recommended ones.

Here are few of them in Ubuntu:

$ apt show gnome-shell gnome-session vanilla-gnome-desktop | grep -e ^Package -e ^Depends -e ^Recommends

Package: gnome-shell
Depends: libatk-bridge2.0-0 (>= 2.5.3), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.14.0), libcanberra-gtk3-0 (>= 0.25), libcanberra0 (>= 0.2), libcroco3 (>= 0.6.2), libecal-1.2-19 (>= 3.17), libedataserver-1.2-23 (>= 3.17.2), libgcr-base-3-1 (>= 3.8.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libgirepository-1.0-1 (>= 1.35.9), libgjs0-libmozjs-52-0, libgjs0g (>= 1.52.1), libglib2.0-0 (>= 2.53.0), libgstreamer1.0-0 (>= 1.4.0), libgtk-3-0 (>= 3.21.6), libical3 (>= 3.0.0), libjson-glib-1.0-0 (>= 0.13.2), libmutter-2-0 (>= 3.28.3), libnm0 (>= 1.0.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpolkit-agent-1-0 (>= 0.99), libpolkit-gobject-1-0 (>= 0.94), libpulse-mainloop-glib0 (>= 0.99.1), libpulse0 (>= 0.99.1), libsecret-1-0 (>= 0.7), libstartup-notification0 (>= 0.11), libsystemd0, libx11-6, libxfixes3, evolution-data-server (>= 3.17.2), gir1.2-accountsservice-1.0, gir1.2-atspi-2.0 (>= 2.9.91), gir1.2-freedesktop, gir1.2-gdesktopenums-3.0 (>= 3.12), gir1.2-geoclue-2.0, gir1.2-gcr-3 (>= 3.7.5), gir1.2-gdm-1.0 (>= 3.18.2), gir1.2-glib-2.0 (>= 1.45.3), gir1.2-gnomebluetooth-1.0 (>= 3.12.0), gir1.2-gnomedesktop-3.0 (>= 3.12.0), gir1.2-gtk-3.0 (>= 3.16), gir1.2-gweather-3.0, gir1.2-ibus-1.0 (>= 1.5.2), gir1.2-mutter-2 (>= 3.27.91), gir1.2-nm-1.0, gir1.2-nma-1.0, gir1.2-pango-1.0, gir1.2-polkit-1.0, gir1.2-rsvg-2.0, gir1.2-soup-2.4 (>= 2.40.1), gir1.2-upowerglib-1.0 (>= 0.99), gjs (>= 1.47.90), gnome-settings-daemon (>= 3.16.0), gnome-shell-common (= 3.28.3-0ubuntu0.18.04.4), ubuntu-wallpapers, gsettings-desktop-schemas (>= 3.21.3), mutter (>= 3.27.91), python3, libglib2.0-bin (>= 2.53.0)
Recommends: xserver-xorg-legacy, bolt (>= 0.2), gkbd-capplet, gnome-control-center, gnome-user-guide, iio-sensor-proxy, unzip, ubuntu-session | gnome-session

Package: gnome-session
Depends: gnome-settings-daemon (>= 3.23.3), gnome-shell (>= 3.25.91-0ubuntu4~), gnome-session-bin (>= 3.28.1-0ubuntu3), gnome-session-bin (<< 3.29), gnome-session-common (= 3.28.1-0ubuntu3), xwayland
Recommends: fonts-cantarell, adwaita-icon-theme-full, gnome-themes-extra

Package: vanilla-gnome-desktop
Depends: adwaita-icon-theme-full, alsa-base, alsa-utils, anacron, at-spi2-core, baobab, bc, ca-certificates, chrome-gnome-shell, dconf-editor, eog, evince, file-roller, fonts-cantarell, fonts-dejavu-core, fonts-freefont-ttf, foomatic-db-compressed-ppds, gdm3, gedit, genisoimage, ghostscript-x, gnome-backgrounds, gnome-calculator, gnome-calendar, gnome-characters, gnome-color-manager, gnome-contacts, gnome-control-center, gnome-disk-utility, gnome-documents, gnome-font-viewer, gnome-initial-setup, gnome-keyring, gnome-logs, gnome-menus, gnome-online-accounts, gnome-online-miners, gnome-screenshot, gnome-session, gnome-session-canberra, gnome-settings-daemon, gnome-shell, gnome-shell-extensions, gnome-sushi, gnome-system-monitor, gnome-terminal, gnome-themes-extra, gnome-todo, gnome-tweaks, gnome-user-docs, gnome-user-share, gsettings-desktop-schemas, gstreamer1.0-alsa, gstreamer1.0-plugins-base-apps, gstreamer1.0-pulseaudio, gvfs-bin, inputattach, libatk-adaptor, libnotify-bin, libsasl2-modules, libu2f-udev, mutter, nautilus, nautilus-extension-brasero, network-manager, openprinting-ppds, printer-driver-pnm2ppa, pulseaudio, rfkill, simple-scan, software-properties-gtk, spice-vdagent, ssh-askpass-gnome, system-config-printer-common, system-config-printer-udev, tracker, ubuntu-drivers-common, ubuntu-release-upgrader-gtk, unzip, update-manager, update-notifier, vanilla-gnome-default-settings, vino, wireless-tools, wpasupplicant, xdg-desktop-portal-gtk, xdg-user-dirs, xdg-user-dirs-gtk, xkb-data, xorg, yelp, zenity, zip, zsync
Recommends: acpi-support, aisleriot, app-install-data-partner, apport-gtk, avahi-autoipd, avahi-daemon, bluez, bluez-cups, brltty, cheese, cups, cups-bsd, cups-client, cups-filters, deja-dup, exfat-utils, firefox, fonts-indic, fonts-kacst-one, fonts-khmeros-core, fonts-lao, fonts-liberation, fonts-lklug-sinhala, fonts-noto-cjk, fonts-sil-abyssinica, fonts-sil-padauk, fonts-thai-tlwg, fonts-tibetan-machine, fonts-ubuntu, fwupd, fwupdate, fwupdate-signed, gnome-accessibility-themes, gnome-bluetooth, gnome-getting-started-docs, gnome-mahjongg, gnome-maps, gnome-mines, gnome-music, gnome-orca, gnome-photos, gnome-software, gnome-software-plugin-flatpak, gnome-sudoku, gnome-weather, gvfs-fuse, hplip, ibus, ibus-gtk, ibus-gtk3, ibus-table, im-config, kerneloops, laptop-detect, libnss-mdns, libpam-gnome-keyring, libproxy1-plugin-gsettings, libproxy1-plugin-networkmanager, libreoffice-calc, libreoffice-gnome, libreoffice-impress, libreoffice-math, libreoffice-ogltrans, libreoffice-pdfimport, libreoffice-style-tango, libreoffice-writer, libwmf0.2-7-gtk, memtest86+, mousetweaks, nautilus-sendto, nautilus-share, network-manager-config-connectivity-ubuntu, network-manager-pptp-gnome, packagekit, pcmciautils, plymouth-theme-ubuntu-gnome-logo, plymouth-theme-ubuntu-gnome-text, policykit-desktop-privileges, ppa-purge, printer-driver-brlaser, printer-driver-c2esp, printer-driver-foo2zjs, printer-driver-m2300w, printer-driver-min12xxw, printer-driver-ptouch, printer-driver-pxljr, printer-driver-sag-gdi, printer-driver-splix, pulseaudio-module-bluetooth, rhythmbox, snapd, speech-dispatcher, totem, transmission-gtk, ubuntu-gnome-wallpapers, usb-creator-gtk, whoopsie, xdg-utils, xul-ext-ubufox

(in Debian/Ubuntu, recommends are installed by default, unless user specifically disables that. I.e. there's much less testing which would find out whether everything expected still works fully if recommends are left out. And all the package dependencies can naturally pull in additional dependencies. With these caveats, the info above should still be useful.)

ahkok commented 5 years ago

We can't rely on how much Ubuntu or debian tests, so unfortunately that information is only casually useful.

bryteise commented 5 years ago

@eero-t At this point I don't think we have enough time to validate splitting the bundle. Work is underway to make finer grain bundles so we might get to this point eventually but this issue isn't the goal of that work and will be more of a byproduct. I'll keep this open and probably comment on it in a month or two as that work progresses.

eero-t commented 5 years ago

@bryteise Gnome isn't a problem for me personally (as I use just self-built Weston), but some other bundles have (at least had) very illogical content. I think worse example of this was phoronix-test-suite (year ago we needed one 200k python2 extension, and only bundle providing it was a multi-GB sized phoronix-test-suite one, instead of something related to python2).

=> any work in splitting things more logically is very much appreciated!

fenrus75 commented 5 years ago

We are refining at a steady pace...

On python2 stuff though... that’s getting kicked out of the os at a steady state as well with the near term upstream eol of python 2... from a security policy perspective we need to not depend on this anymore before that eol date

On Wed, Feb 13, 2019 at 03:53 eero-t notifications@github.com wrote:

@bryteise https://github.com/bryteise Gnome isn't a problem for me personally (as I use just self-built Weston), but some other bundles have (at least had) very illogical content. I think worse example of this was phoronix-test-suite (year ago we needed one 200k python2 extension, and only bundle providing it was a multi-GB sized phoronix-test-suite one, instead of something related to python2).

=> any work in splitting things more logically is very much appreciated!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clearlinux/distribution/issues/423#issuecomment-463171493, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPeFV4SN0I6Gg4CHZ2tTYiTa72FBOxPks5vM_ybgaJpZM4axcMn .

eero-t commented 5 years ago

I think a minimum splitting policy could be that libraries that can be used also by other applications (i.e. ones that are in standard locations), are bundled separately from the applications using them. In the phoronix-test-suite case, they could be e.g. in a separate phoronix-test-suite-libs package, if there isn't more logical place for them.

As to Gnome, additional splitting besides libs is bit harder because there are also services and deps for those can't be detected as easily.

We can't rely on how much Ubuntu or debian tests, so unfortunately that information is only casually useful.

Validity of that information:

Package dependencies for direct library linkage, along with library (symbol) versioning is auto-generated by DEB packaging tools, so that should always be correct. Other dependencies are added manually to packages. I assume same is also the case with RPMs.

Ubuntu and Debian (where Ubuntu gets its Gnome packages) have enough desktop users, that I would imagine any package dependency issues with the overall end result to surface immediately and be fixed. While I concur there to be much less testing for configurations where a non-default subset of things is installed, I would assume e.g. above listed 3 high level meta-packages to have enough coverage (I've even used them myself on some machines).

Usefulness of it:

Mapping the package names to RPM names can be anything but straightforward, so your upstream should be better example than Ubuntu/Debian (my examples were from Ubuntu because last time I've used RPM based distros was decade ago). If your upstream RPM distro has similar Gnome meta-packages, using & testing their deps (first on that distro) could be a good starting point. You could even ask interested volunteers for your upstream distro meta-package testing, instead of doing it yourself.

PS. We updated all our Python scripts to support python3 last summer, so we don't anymore have a problem with python2 stuff.

eero-t commented 5 years ago

I would assume e.g. above listed 3 high level meta-packages to have enough coverage

Quick comment from nearby Debian Developer; there's no policy mandating testing for meta-packages, they're just a convenience for simplifying package dependencies.

One way to gauge testing coverage, would be to look into (opt-in) package popularity-contest statistics:

And compare its statistics to most-installed package pulling it in. That difference tells how many installs there are that have "tested" having just the indicated (meta-)package.

Doing this showed that the difference for above 3 packages are pretty small, and (Ubuntu specific) vanilla-gnome-desktop package total install base is too small (according to popcon) to be useful => ignore my comments about Ubuntu having reasonable testing coverage for intermediate Gnome meta-packages

bryteise commented 5 years ago

I would say my long term goal is to have package level bundles for everything that makes sense. I'm not interested in having subpackage level splitting (-bin, -lib style) at this time though.

bryteise commented 5 years ago

The desktop bundle has gone through a few rounds of also-add work and so is able to be slimmed down almost to the point of only gnome required content. I note some of the extensions and other packages can't be removed but I am going to close out this generic issue in favor of specific requests at this point.