Use of 'recommends' and 'suggests'
Hi, follow-up on my recent dependency mail, I was able to trace some dependencies: python3-weasyprint requires python3-FontTools python3-FontTools requires python3-sympy python3-sympy requires python3-mpmath >= 0.19 python3-sympy recommended python3-jupyter_ipython (comes from python3-ipython) python3-ipython recommended jupyter jupyter recommended jupyter-qtconsole jupyter-qtconsole requires python3-qtconsole = 5.2.1 python3-qtconsole requires python3-qt5 Looking at python-sympy in comaprison to https://packages.debian.org/sid/python3-sympy Debian lists the ipyton stuff under 'enhances', not even 'suggests' - which leads to the question, when to properly use recommends and suggests [1], and if not 'suggets may be the better approach here and there. Suggestions? Cheers Axel [1] https://en.opensuse.org/openSUSE:Build_Service_Tutorial#Create_Patterns
On 2/16/22 21:15, Axel Braun wrote:
Hi,
follow-up on my recent dependency mail, I was able to trace some dependencies:
python3-weasyprint requires python3-FontTools python3-FontTools requires python3-sympy python3-sympy requires python3-mpmath >= 0.19 python3-sympy recommended python3-jupyter_ipython (comes from python3-ipython) python3-ipython recommended jupyter
jupyter recommended jupyter-qtconsole jupyter-qtconsole requires python3-qtconsole = 5.2.1 python3-qtconsole requires python3-qt5
Looking at python-sympy in comaprison to https://packages.debian.org/sid/python3-sympy Debian lists the ipyton stuff under 'enhances', not even 'suggests' - which leads to the question, when to properly use recommends and suggests [1], and if not 'suggets may be the better approach here and there.
Suggestions?
From memory suggests on openSUSE works very differently to Debian, its a while since I used debian though. On openSUSE Suggests isn't very useful for much, really its only useful for cases like if something requires "Display-Manager" and we have multiple choices (sddm, lightdm, gdm) and nothing else has selected one we can use "Suggests: lightdm" to tell zypper etc to install lightdm if it doesn't know what to choose. Traditionally on openSUSE we've wanted to give users "The best possible experience" which means if something "enhances" an app ie makes it better we tend to Recommend it (or in some cases require it) to make sure that its installed to give users the best possible experience, then users can choose to lock packages or use no-recommends if thats not what they desire. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Wed, 2022-02-16 at 21:39 +1030, Simon Lees wrote:
From memory suggests on openSUSE works very differently to Debian, its a while since I used debian though. On openSUSE Suggests isn't very useful for much, really its only useful for cases like if something requires "Display-Manager" and we have multiple choices (sddm, lightdm, gdm) and nothing else has selected one we can use "Suggests: lightdm" to tell zypper etc to install lightdm if it doesn't know what to choose.
zypper does basiclaly, what RPM says it should do: https://rpm-software-management.github.io/rpm/manual/dependencies.html === Weak dependencies In addition to the strong dependencies created by Requires, there are 4 dependencies that are completely ignored by rpm itself. Their purpose is to be used by dependency solvers to make choices about what packages to install. They come in two levels of strength: Weak: By default the dependency solver shall attempt to process the dependency as though it were strong. If this is results in an error then they should be ignored and not trigger an error or warning. Very weak: By default the dependency solver shall ignore them. But they may be used to show the matching packages as option to the user. === Weak are 'recommends and supplements', very weak are 'suggests and enhances'. zypper lists 'usggested' packages in the output, but does not install them; the fact that we use it to give some hints to break some choices for zypper is a SUSE-addition (not sure if other RPM package managers handle it that way too) General rule applied is: * Pkg X needs A to run => Requires * PKG X can use B, and it makes sense for most users => Recommends * PKG X can integrate with C => Suggests (or nothing; as it would only add noise on a zypper dup call) The 'Requires' case is pretty obvious; Recommends is mostly a decision by the package maintainer, who decides what 'his users' would expect from the application. He might know, he might have different usecases than you, but at least with recommends you have a chance to break it. Evince is a prety good example there: * It's a document viewer, based on plugins; there exist n plugins * Traditionally, evince was known as pdf viewer: so we opted for the pdfplugin to supplement evince, as strictly speaking, the plugin is not needed * The other plugins (ps, tiff, xps, djvu) are marked as enhances, so arenot installed by default. Is this correct? For most people probably, for some the app misses features they would expect. No answer satisfy all users. IMHO it is best to work out with the respetive package maintainers based on various observations In the specific case,
python3-sympy recommended python3-jupyter_ipython (comes from python3-ipython)
That's something for the package maintainers to decide; from a gut feel, I'd say ipython is probably not used by the majority of the users (but then, it's IPython/Jupyter LaTeX printing - and I am biased against tex on my system anyway) Cheers, Dominique
Hello, only an addedum to emphasize a specific point: On 2022-02-16 13:23, Dominique Leuenberger / DimStar wrote:
* Pkg X needs A to run => Requires ... The 'Requires' case is pretty obvious
I think the 'Requires' case is only clear when it is written more to the point: Pkg X cannot run without A => X Requires A My point is that "Pkg X needs A to run" could be misunderstood as "normally users of X need A to run X for usual use cases". But actually X may run even without A (for specific use cases like some minimal use cases in special unusual environments). When in this case X Requires A it is impossible for users to install only X without A without breaking RMP dependencies i.e. it is impossible for users to install only X without A in a clean way regardless that X can run even without A. Bottom line: What is not strictly required schould not be specified as 'Requires' but only as 'Recommends'. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
Johannes Meixner composed on 2022-02-16 13:51 (UTC+0100):
only an addedum to emphasize a specific point:
Dominique Leuenberger / DimStar wrote:
* Pkg X needs A to run => Requires ... The 'Requires' case is pretty obvious
This is not the way it is for fonts. Packagers shouldn't be /requiring/ particular font families when any ordinary TTF or OTF font will serve the purpose of putting legible fonts where needed, but that's the way it is (or was until recently with one or more), with: adobe-sourcesanspro-fonts cantarell-fonts google-opensans-fonts google-poppins-fonts hack-fonts noto-sans-fonts raleway-fonts I suppose there may be more fonts "required" by DEs I've never installed. Also, glibc-locale-base gets the job done, yet several packages require glibc-locale.
I think the 'Requires' case is only clear when it is written more to the point:
Pkg X cannot run without A => X Requires A
My point is that "Pkg X needs A to run" could be misunderstood as "normally users of X need A to run X for usual use cases".
But actually X may run even without A (for specific use cases like some minimal use cases in special unusual environments). When in this case X Requires A it is impossible for users to install only X without A without breaking RMP dependencies i.e. it is impossible for users to install only X without A in a clean way regardless that X can run even without A.
Bottom line: What is not strictly required schould not be specified as 'Requires' but only as 'Recommends'.
Amen!!! -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Wed, 2022-02-16 at 08:58 -0500, Felix Miata wrote:
Johannes Meixner composed on 2022-02-16 13:51 (UTC+0100):
only an addedum to emphasize a specific point:
Dominique Leuenberger / DimStar wrote:
* Pkg X needs A to run => Requires ... The 'Requires' case is pretty obvious
This is not the way it is for fonts. Packagers shouldn't be /requiring/ particular font families when any ordinary TTF or OTF font will serve the purpose of putting legible fonts where needed, but that's the way it is (or was until recently with one or more), with:
adobe-sourcesanspro-fonts cantarell-fonts google-opensans-fonts google-poppins-fonts hack-fonts noto-sans-fonts raleway-fonts
I suppose there may be more fonts "required" by DEs I've never installed.
I understand part of the frustration - but in case of e.g. GNOME, the theme clearly specifies a font as part of the css properties and the branding defines a default font. That one being required sounds plausible (especially considering how often the recommendation of --no- recommends is being copied around)
Also, glibc-locale-base gets the job done, yet several packages require glibc-locale.
That's just been cleaned up for example for RPM; Looking at the entire distro, I can see: zypper se -t package -x --requires glibc-locale 12 packages and 2 patterns requiring glibc-locale. Surely something that can be cleaned up. Feel free to lead the effort!
Cheers, Dominique
On Wed, 2022-02-16 at 15:16 +0100, Dominique Leuenberger / DimStar
This is not the way it is for fonts. Packagers shouldn't be /requiring/ particular font families when any ordinary TTF or OTF font will serve the purpose of putting legible fonts where needed, but that's the way it is (or was until recently with one or more), with:
adobe-sourcesanspro-fonts cantarell-fonts google-opensans-fonts google-poppins-fonts hack-fonts noto-sans-fonts raleway-fonts
I suppose there may be more fonts "required" by DEs I've never installed.
I understand part of the frustration - but in case of e.g. GNOME, the theme clearly specifies a font as part of the css properties and the branding defines a default font. That one being required sounds plausible (especially considering how often the recommendation of -- no- recommends is being copied around)
Perhaps, but is the following also necessary? # zypper remove google-opensans-fonts The following 6 packages are going to be REMOVED: daps google-opensans-fonts suse-xsl-stylesheets yast2-qt-branding- openSUSE yast2-theme yast2-x11 # zypper remove adobe-sourcesanspro-fonts The following 4 packages are going to be REMOVED: adobe-sourcesanspro-fonts yast2-qt-branding-openSUSE yast2-theme yast2-x11 # zypper remove google-poppins-fonts The following 3 packages are going to be REMOVED: google-poppins-fonts yast2-theme yast2-x11 YaST seems to pull in 3 different font families. Martin
On Mi, Feb 16 2022 at 15:49:07 +0100, Martin Wilck
Perhaps, but is the following also necessary?
# zypper remove google-opensans-fonts The following 6 packages are going to be REMOVED: daps google-opensans-fonts suse-xsl-stylesheets yast2-qt-branding- openSUSE yast2-theme yast2-x11
# zypper remove adobe-sourcesanspro-fonts The following 4 packages are going to be REMOVED: adobe-sourcesanspro-fonts yast2-qt-branding-openSUSE yast2-theme yast2-x11
# zypper remove google-poppins-fonts The following 3 packages are going to be REMOVED: google-poppins-fonts yast2-theme yast2-x11
YaST seems to pull in 3 different font families.
Actually, that seems like a bug, opensans and ssp should only be required by yast2-qt-branding-openSUSE (which shouldn't be required on non-installation systems like live cd and installation images), and I assume the other font is for SLE theme, which should be required on SLE only. Those 2 packages in those scenarios do require those fonts as they are a part of qss shipped as part of those packages. LCP [Sasi] https://lcp.world/
On Wed, 2022-02-16 at 15:49 +0100, Martin Wilck wrote:
On Wed, 2022-02-16 at 15:16 +0100, Dominique Leuenberger / DimStar
I understand part of the frustration - but in case of e.g. GNOME, the theme clearly specifies a font as part of the css properties and the branding defines a default font. That one being required sounds plausible (especially considering how often the recommendation of -- no- recommends is being copied around)
Perhaps, but is the following also necessary?
# zypper remove google-opensans-fonts The following 6 packages are going to be REMOVED: daps google-opensans-fonts suse-xsl-stylesheets yast2-qt-branding- openSUSE yast2-theme yast2-x11
# zypper remove adobe-sourcesanspro-fonts The following 4 packages are going to be REMOVED: adobe-sourcesanspro-fonts yast2-qt-branding-openSUSE yast2-theme yast2-x11
# zypper remove google-poppins-fonts The following 3 packages are going to be REMOVED: google-poppins-fonts yast2-theme yast2-x11
YaST seems to pull in 3 different font families.
yast2-qt-branding-openSUSE requires two of them:
rpm -qR yast2-qt-branding-openSUSE adobe-sourcesanspro-fonts google-opensans-fonts
Which matches the requirements in /usr/share/YaST2/theme/current/wizard/installation.qss * { font-family:"Source Sans Pro",sans; font-size: 10.5pt } #DialogHeadingLeft { font-family: "Open Sans Condensed", Sans-serif; font-size: 18pt; color: #333; qproperty-alignment:AlignLeft; font-weight:bold; } (and some more definitions) - so, this package asking for those two fonts sounds correct and yast2-theme the third one:
rpm -qR yast2-theme google-poppins-fonts
At least with a very quick glance, I can't see why this one seems needed; Sounds like a bug report for the YaST Team to validate. Cheers, Dominique
* Martin Wilck
On Wed, 2022-02-16 at 15:16 +0100, Dominique Leuenberger / DimStar
This is not the way it is for fonts. Packagers shouldn't be /requiring/ particular font families when any ordinary TTF or OTF font will serve the purpose of putting legible fonts where needed, but that's the way it is (or was until recently with one or more), with:
adobe-sourcesanspro-fonts cantarell-fonts google-opensans-fonts google-poppins-fonts hack-fonts noto-sans-fonts raleway-fonts
I suppose there may be more fonts "required" by DEs I've never installed.
I understand part of the frustration - but in case of e.g. GNOME, the theme clearly specifies a font as part of the css properties and the branding defines a default font. That one being required sounds plausible (especially considering how often the recommendation of -- no- recommends is being copied around)
Perhaps, but is the following also necessary?
# zypper remove google-opensans-fonts The following 6 packages are going to be REMOVED: daps google-opensans-fonts suse-xsl-stylesheets yast2-qt-branding- openSUSE yast2-theme yast2-x11
# zypper remove adobe-sourcesanspro-fonts The following 4 packages are going to be REMOVED: adobe-sourcesanspro-fonts yast2-qt-branding-openSUSE yast2-theme yast2-x11
# zypper remove google-poppins-fonts The following 3 packages are going to be REMOVED: google-poppins-fonts yast2-theme yast2-x11
YaST seems to pull in 3 different font families.
more: # zypper -v rm *-lang Verbosity: 2 Non-option program arguments: '*-lang' Initializing Target Reading installed packages... Force resolution: Yes Selecting 'gimp-gap-lang-2.6.0-29.30.noarch' for removal. Selecting 'iso-codes-lang-4.9.0-1.1.noarch' for removal. Selecting 'libKF5JobWidgets5-lang-5.90.0-1.2.noarch' for removal. Selecting 'libKF5WidgetsAddons5-lang-5.90.0-1.2.noarch' for removal. Selecting 'po4a-lang-0.66-1.1.noarch' for removal. [TechPreview] $ZYPP_SINGLE_RPMTRANS=1 : New rpm install backend is enabled If you find any bugs or issues please let us know: https://bugzilla.opensuse.org/ Component: libzypp (or zypper) And please attach the /var/log/zypper.log to the bug report. Resolving package dependencies... Force resolution: Yes The following 245 packages are going to be REMOVED: akonadi-calendar-tools 21.12.2-1.1 akonadi-contact 21.12.2-1.1 akonadi-import-wizard 21.12.2-1.1 akonadi-plugin-calendar 21.12.2-1.1 akonadi-plugin-contacts 21.12.2-1.1 akonadi-plugin-kalarmcal 21.12.2-1.1 akonadi-plugin-mime 21.12.2-1.1 akonadi-search 21.12.2-1.1 akonadi-server 21.12.2-1.1 akonadi-server-sqlite 21.12.2-1.1 akregator 21.12.2-1.1 ark 21.12.2-1.1 baloo5-file 5.90.0-1.1 baloo5-imports 5.90.0-1.1 baloo5-kioslaves 5.90.0-1.1 baloo5-tools 5.90.0-1.1 baloo5-widgets 21.12.2-1.1 basket 2.50+git20190227.a801db1-3.72 bluedevil5 5.24.0-1.1 breeze 5.24.0-1.1 breeze5-decoration 5.24.0-1.1 breeze5-style 5.24.0-1.1 colord-kde 0.5.0-14.27 digikam 7.5.0-226.6 digikam-plugins 7.5.0-226.6 discover 5.24.0-2.1 discover-backend-flatpak 5.24.0-2.1 dolphin 21.12.2.1-1.1 dolphin-part 21.12.2.1-1.1 drkonqi5 5.24.0-1.1 ffmpegthumbs 21.12.2-1.1 filelight 21.12.2-1.1 frameworkintegration-plugin 5.90.0-2.1 gimp-gap 2.6.0-29.30 gimp-gap-lang 2.6.0-29.30 grantleetheme 21.12.2-1.1 gwenview5 21.12.2-1.1 iso-codes-lang 4.9.0-1.1 juk 21.12.2-1.1 k3b 21.12.2-1.1 kaccounts-integration 21.12.2-1.1 kaccounts-providers 21.12.2-1.1 kactivitymanagerd 5.24.0-1.1 kaddressbook 21.12.2-1.1 kate 21.12.2-1.1 kate-plugins 21.12.2-1.1 kcalc 21.12.2-1.1 kcalutils 21.12.2-1.1 kcm_sddm 5.24.0-1.1 kcm_tablet 3.2.0-5.1 kde-cli-tools5 5.24.0-1.1 kde-gtk-config5 5.24.0-1.1 kde-gtk-config5-gtk3 5.24.0-1.1 kde-print-manager 21.12.2-1.1 kdeclarative-components 5.90.0-1.2 kdeconnect-kde 21.12.2-1.1 kded 5.90.0-1.1 kdegraphics-thumbnailers 21.12.2-1.1 kdelibs4support 5.90.0-1.1 kdenetwork-filesharing 21.12.2-1.1 kdepim-addons 21.12.2-1.1 kdepim-runtime 21.12.2-1.1 kdf 21.12.2-1.1 kdialog 21.12.2-1.1 kfilemetadata5 5.90.0-1.1 kgamma5 5.24.0-1.1 khelpcenter5 21.12.2-1.1 khotkeys5 5.24.0-1.1 kinfocenter5 5.24.0-2.1 kinit 5.90.0-1.1 kio 5.90.0-2.1 kio-core 5.90.0-2.1 kio-extras5 21.12.2-1.1 kio-gdrive 21.12.2-1.1 kio_iso 2.7.2-48.48 kipi-plugins 21.12.2-1.1 kldap 21.12.2-1.1 kleopatra 21.12.2-1.1 kmail 21.12.2-1.1 kmail-account-wizard 21.12.2-1.1 kmailtransport 21.12.2-1.1 kmenuedit5 5.24.0-1.1 kmozillahelper 5.0.6-1.10 knemo 0.7.7git.20191016T164055~e5a3984-4.46 knewstuff 5.90.0-1.1 knewstuff-imports 5.90.0-1.1 knotes 21.12.2-1.1 konqueror 21.12.2-1.1 konsole 21.12.2-1.1 konsole-part 21.12.2-1.1 kontact 21.12.2-1.1 konversation 21.12.2-1.1 korganizer 21.12.2-1.1 kpackage 5.90.0-1.1 kpeople5 5.90.0-1.1 krename 5.0.1-42.27 krita 5.0.2-2.2 kross 5.90.0-1.1 krusader 2.7.2-48.48 kscreen5 5.24.0-2.1 kscreenlocker 5.24.0-1.1 kservice 5.90.0-1.1 ksshaskpass5 5.24.0-1.1 ksysguard5 5.22.0-2.4 ksystemstats5 5.24.0-1.1 ktexteditor 5.90.0-1.2 ktnef 21.12.2-1.1 kwallet-tools 5.90.0-1.1 kwalletd5 5.90.0-1.1 kwalletmanager5 21.12.2-1.1 kwin5 5.24.0-2.1 libKF5AkonadiAgentBase5 21.12.2-1.1 libKF5AkonadiCalendar5 21.12.2-1.1 libKF5AkonadiContact5 21.12.2-1.1 libKF5AkonadiCore5 21.12.2-1.1 libKF5AkonadiMime5 21.12.2-1.1 libKF5AkonadiNotes5 21.12.2-1.1 libKF5AkonadiSearch 21.12.2-1.1 libKF5AkonadiWidgets5 21.12.2-1.1 libKF5AkonadiXml5 21.12.2-1.1 libKF5AlarmCalendar5 21.12.2-1.1 libKF5Baloo5 5.90.0-1.1 libKF5BalooEngine5 5.90.0-1.1 libKF5Bookmarks5 5.90.0-1.2 libKF5CalendarSupport5 21.12.2-1.1 libKF5CalendarUtils5 21.12.2-1.1 libKF5Cddb5 21.12.2-1.1 libKF5ConfigWidgets5 5.90.0-2.1 libKF5ContactEditor5 21.12.2-1.1 libKF5Contacts5 5.90.0-1.1 libKF5DAV5 5.90.0-1.1 libKF5Declarative5 5.90.0-1.2 libKF5Emoticons5 5.90.0-1.1 libKF5EventViews5 21.12.2-1.1 libKF5GrantleeTheme5 21.12.2-1.1 libKF5Gravatar5 21.12.2-1.1 libKF5I18n5 5.90.0-1.1 libKF5IMAP5 21.12.2-1.1 libKF5IconThemes5 5.90.0-1.1 libKF5IdentityManagement5 21.12.2-1.1 libKF5IncidenceEditor5 21.12.2-1.1 libKF5JobWidgets5-lang 5.90.0-1.2 libKF5JsEmbed5 5.90.0-1.1 libKF5KCMUtils5 5.90.0-1.1 libKF5KDELibs4Support5 5.90.0-1.1 libKF5KHtml5 5.90.0-1.2 libKF5Kipi32_0_0 21.12.2-1.1 libKF5KontactInterface5 21.12.2-1.1 libKF5Ldap5 21.12.2-1.1 libKF5Libkdepim5 21.12.2-1.1 libKF5Libkleo5 21.12.2-1.1 libKF5MailCommon5 21.12.2-1.1 libKF5MailImporter5 21.12.2-1.1 libKF5MailImporterAkonadi5 21.12.2-1.1 libKF5MailTransport5 21.12.2-1.1 libKF5MailTransportAkonadi5 21.12.2-1.1 libKF5Mbox5 21.12.2-1.1 libKF5Mime5 21.12.2-1.1 libKF5NewStuff5 5.90.0-1.1 libKF5NewStuffCore5 5.90.0-1.1 libKF5NotifyConfig5 5.90.0-1.1 libKF5Parts5 5.90.0-1.1 libKF5PimCommon5 21.12.2-1.1 libKF5PimCommonAkonadi5 21.12.2-1.1 libKF5PimTextEdit5 21.12.2-1.1 libKF5Plasma5 5.90.0-1.1 libKF5Pty5 5.90.0-1.1 libKF5PurposeWidgets5 5.90.0-1.1 libKF5QuickAddons5 5.90.0-1.2 libKF5Runner5 5.90.0-1.1 libKF5Sane5 21.12.2-1.1 libKF5Style5 5.90.0-2.1 libKF5Su5 5.90.0-1.1 libKF5TextWidgets5 5.90.0-1.1 libKF5Tnef5 21.12.2-1.1 libKF5UnitConversion5 5.90.0-1.1 libKF5WidgetsAddons5-lang 5.90.0-1.2 libKF5XmlGui5 5.90.0-1.1 libKF5XmlRpcClient5 5.90.0-1.1 libKPimAddressbookImportExport5 21.12.2-1.1 libKPimGAPIContacts5 21.12.2-1.1 libKPimImportWizard5 21.12.2-1.1 libKPimItinerary5 21.12.2-1.1 libKPimSMTP5 21.12.2-1.1 libKScreenLocker5 5.24.0-1.1 libKSeExpr4 4.0.4.0-12.4 libKSysGuardSystemStats1 5.24.0-1.1 libdigikamcore7 7.5.0-226.6 libkaccounts2 21.12.2-1.1 libkdecorations2-5 5.24.0-1.1 libkdepim 21.12.2-1.1 libkerfuffle21 21.12.2-1.1 libkioarchive5 21.12.2-1.1 libksieve 21.12.2-1.1 libksieve5 21.12.2-1.1 libksysguard5 5.24.0-1.1 libksysguard5-imports 5.24.0-1.1 libksysguard5-plugins 5.24.0-1.1 libkwalletbackend5-5 5.90.0-1.1 libreoffice-qt5 7.2.5.1-3.1 libsvn_auth_kwallet-1-0 1.14.1-5.5 marble 21.12.2-1.1 marble-data 21.12.2-1.1 marble-doc 21.12.2-1.1 marble-kde 21.12.2-1.1 mbox-importer 21.12.2-1.1 messagelib 21.12.2-1.1 milou5 5.24.0-1.1 mobipocket 21.12.2-1.1 okular 21.12.2-1.1 patterns-kde-kde 20220203-1.1 patterns-kde-kde_plasma 20220203-1.1 pim-data-exporter 21.12.2-1.1 pim-sieve-editor 21.12.2-1.1 plasma-browser-integration 5.24.0-1.1 plasma-framework 5.90.0-1.1 plasma-framework-components 5.90.0-1.1 plasma-nm5 5.24.0-1.1 plasma5-addons 5.24.0-1.1 plasma5-defaults-openSUSE 84.87~git20220116T220745~fffd234-1.1 plasma5-desktop 5.24.0-1.1 plasma5-integration-plugin 5.24.0-1.1 plasma5-pa 5.24.0-2.1 plasma5-session 5.24.0-1.2 plasma5-session-wayland 5.24.0-1.2 plasma5-theme-openSUSE 84.87~git20220116T220745~fffd234-1.1 plasma5-workspace 5.24.0-1.2 plasma5-workspace-branding-openSUSE 84.87~git20220116T220745~fffd234-1.1 plasma5-workspace-libs 5.24.0-1.2 po4a-lang 0.66-1.1 polkit-kde-agent-5 5.24.0-1.1 powerdevil5 5.24.0-1.1 purpose 5.90.0-1.1 qqc2-desktop-style 5.90.0-1.2 sddm 0.19.0-4.5 sddm-branding-openSUSE 0.19.0-4.5 sddm-theme-openSUSE 84.87~git20220116T220745~fffd234-1.1 showfoto 7.5.0-226.6 skanlite 21.12.2-1.1 smb4k 3.1.1-2.1 spectacle 21.12.2-1.1 systemsettings5 5.24.0-1.1 webenginepart 21.12.2-1.1 xdg-desktop-portal-kde 5.24.0-1.1 yakuake 21.12.2-1.1 The following 2 patterns are going to be REMOVED: kde 20220203-1.1 kde_plasma 20220203-1.1 245 packages to remove. After the operation, 560.8 MiB will be freed. just to remove *-lang packages which are not needed for us-english. 21.12.2-1.1
1/2 gigabyte
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc What sort of day was it? A day like all days, filled with those events that alter and illuminate our times...
Dominique Leuenberger / DimStar composed on 2022-02-16 15:16 (UTC+0100):
I understand part of the frustration - but in case of e.g. GNOME, the theme clearly specifies a font as part of the css properties and the branding defines a default font. That one being required sounds plausible (especially considering how often the recommendation of --no- recommends is being copied around)
Part of the design of CSS is the precept that the user has ultimate control, for a11y and u9y reasons, if not basic respect. Hard requires violate the precept. Branding via fonts should never be a hard requirement in a public project. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Wednesday 2022-02-16 13:51, Johannes Meixner wrote:
only an addedum to emphasize a specific point:
On 2022-02-16 13:23, Dominique Leuenberger / DimStar wrote:
* Pkg X needs A to run => Requires ... The 'Requires' case is pretty obvious
I think the 'Requires' case is only clear when it is written more to the point: Pkg X cannot run without A => X Requires A
My point is that "Pkg X needs A to run" could be misunderstood as "normally users of X need A to run X for usual use cases". But actually X may run even without A (for specific use cases like some minimal use cases in special unusual environments).
Bottom line: What is not strictly required schould not be specified as 'Requires' but only as 'Recommends'.
The thing is, evince without any document plugins is like a kernel without filesystem support. You can run it technically speaking, but it's dead weight at that point for the 99th percentile.
Hello, On 2022-02-16 15:48, Jan Engelhardt wrote:
On Wednesday 2022-02-16 13:51, Johannes Meixner wrote:
only an addedum to emphasize a specific point:
On 2022-02-16 13:23, Dominique Leuenberger / DimStar wrote:
* Pkg X needs A to run => Requires ... The 'Requires' case is pretty obvious
I think the 'Requires' case is only clear when it is written more to the point: Pkg X cannot run without A => X Requires A
My point is that "Pkg X needs A to run" could be misunderstood as "normally users of X need A to run X for usual use cases". But actually X may run even without A (for specific use cases like some minimal use cases in special unusual environments).
Bottom line: What is not strictly required schould not be specified as 'Requires' but only as 'Recommends'.
The thing is, evince without any document plugins is like a kernel without filesystem support. You can run it technically speaking, but it's dead weight at that point for the 99th percentile.
as far as I see you proved my point. It does not belong to the evince RPM to enforce the user to have some specific plugin installed. If evince without any document plugins is not useful then the evince RPM may recommend some usually needed plugins (i.e. usually needed by the user but not technically required). But actually what is usually needed by the user should be better specified via patterns. As far as I know patterns are basically empty RPMs that only have dependencies. So I think patterns can require and recommend things. For example a "desktop" pattern may even require evince (if that desktop could not work normally without it) and also require some standard evince document plugins which are considered to be mandatory for "desktop" usage. A user who wants his explicit specific set of RPMs could remove such a "desktop" pattern (provided that pattern is not required but only recommended) and install evince with plugins as he specifically wants. A theoretical example: Assume there are two desktop environments. "DesktopA" uses "reader1" for "this" documents and "reader2" for "that" documents but "DesktopB" uses "reader1" for "that" documents and "reader2" for "this" documents. It is impossible to specify this two use cases in the "reader1" and "reader2" RPMs because both contradict (recommends vs. requires don't help here). So neither "reader1" nor "reader2" should specify its use case (because one RPM spec file can only specify one "hardcoded" use case). Instead there should be "DesktopA" and "DesktopB" patterns so that each use case can be specified separatedly and the user has the freedom of choice, cf. "freedom 0" at https://www.gnu.org/philosophy/free-sw.html when "the program" is a whole Linux distribution. By the way: Users who globally refuse recommeded packages get what they ask for: They get full control over all installed RPMs only limited by what is actually mandatory which means they are fully responsible for all their installed RPMs - of course. In the end it is about if there is "freedom and final power at the user" or "final power at the Linux distributor". Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
On 17.02.22 08:15, Johannes Meixner wrote:
By the way: Users who globally refuse recommeded packages get what they ask for: They get full control over all installed RPMs only limited by what is actually mandatory which means they are fully responsible for all their installed RPMs - of course.
And they usually like it that way ;-)
In the end it is about if there is "freedom and final power at the user" or "final power at the Linux distributor".
Exactly. I was surprised by evince being unable to display *anything* after updating from Leap 42.3 to 15.0 (not sure about the exact numbers), but after I found out what caused the "problem", I actually was delighted that it did not require everything-and-the-kitchen-sink but let me choose the plugins I needed. Have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
participants (10)
-
Axel Braun -
Dominique Leuenberger / DimStar -
Felix Miata -
Jan Engelhardt -
Johannes Meixner -
Martin Wilck -
Patrick Shanahan -
Sasi Olin -
Simon Lees -
Stefan Seyfried