Re: Project Improvements
Op 23-05-2022 om 13:00 schreef Fabio Fantoni: Il 23/05/2022 01:42, Glauber Baldez ha scritto: Some considerations for project improvement: 1. Debian should already offer users a minimal installation mode similar to Ubuntu, without media players, games and office applications. 2. Debian should follow Doug Gwyn's words in stating that Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing smart things; the operating system must trust the user. Writing this, a big problem is not knowing how to differentiate the desktop environment from desktop applications, treating these factors as if they were the same thing. For example, the user cannot be prevented from removing the default web browser (desktop application) to replace it with another one of their choice as this breaks the desktop environment. Where's the freedom? I repeat again: desktop environment and desktop applications are not the same thing, so they shouldn't be treated as such either. Hi, thanks for your mail with suggestion to improve the project. I'm one maintainer of the cinnamon team, in the years I did some changes to make possible to have minimal installation of cinnamon. cinnamon (the package) without recommends is the very minimal. In some cases users had reported changes that had added unnecessary packages to the dependencies that I had then modified or removed and made some tests both on debian and ubuntu but unfortunately I can not do them often because they take a long time (both installation and quick functional tests) so report or advice from users are always useful. cinnamon-core and cinnamon-desktop-environment are 2 metapackage, the first for minimal desktop environment and second full. In the full one there are browser, media player and mail client are depends (libreoffice instead is already in recommends), one users recently required to remove browser and media player from depends but I added some alternative instead (in 5.2.2) thinking that are "essential software" for a full DE metapackage without recommends. I was wrong and I should move them to the recommends? Any reply/suggestion from other maintainers or users is appreciated. Sorry for my bad english. In my opinion it would be better to use recommends. I like to use a mail client myself, but many people want to use webmail these days for example. And many people don't use an IM client. Some people like to install a browser from outside Debian, like "Brave Browser" or a flatpack with the latest Firefox. Such a meta-package is good to install many packages at once, but it would be nice to have the possibility to remove them individually. I support many people with Debian, what I often see is that they remove a package, and then also the meta-package is removed. And later all dependencies of the meta-package are removed by accident. Just my 2 cents... With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl
Bug#1011608: ITP: python-flit-scm -- A PEP 518 build backend that uses setuptools_scm and flit
Package: wnpp Severity: wishlist Owner: Agathe Porte X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, deb...@microjoe.org * Package name: python-flit-scm Version : 1.5.0 Upstream Author : Will Da Silva * URL : https://gitlab.com/WillDaSilva/flit_scm * License : MIT Programming Lang: Python Description : A PEP 518 build backend that uses setuptools_scm and flit This package makes setuptools_scm compatible with flit. It is a dependency of python-exceptiongroup that is ITP #1011552. I intent to maintain this package under the umbrella of the Debian Python Team.
Bug#1011631: ITP: python3-dmm -- distribution management modules/toolkit
Package: wnpp Severity: wishlist Owner: Jonathan Carter X-Debbugs-Cc: debian-devel@lists.debian.org, j...@debian.org * Package name: python3-dmm Version : 0.0.1 Upstream Author : Jonathan Carter * URL : https://salsa.debian.org/jcc/distribution-management-modules * License : ISC Programming Lang: Python Description : distribution management modules/toolkit Modules and toolkit that makes taking care of Linux distribution tasks easier. Its initial set of modules allow you to configure tools like. apt, grub, squashfs (among others) and actions from these modules can be stringed together using recipes (which are yaml files).
Re: Project Improvements
On Wed, May 25, 2022 at 10:33:22AM +0200, Paul van der Vlis wrote: > I support many people with Debian, what I often see is that they remove a > package, and then also the meta-package is removed. And later all > dependencies of the meta-package are removed by accident. Not to rain on your parade, but those people should consider upgrading their Debian installations as since at least apt version 1.1 shipped before current old-old-stable (that is, they run at best Debian 8 jessie which is covered only by Extended LTS) apt actually marks dependencies of packages in section metapackages as manually installed if the metapackage is removed due to the removal of one of its dependencies – but doesn't if you decide to remove the metapackage explicitly. So, given: Package: mydesktop Depends: texteditor, browser Section: metapackages And mydesktop manual, the rest auto-installed: $ apt autoremove => nothing to be done $ apt autoremove mydesktop => removes also texteditor & browser $ apt autoremove texteditor => removes also mydesktop, but marks browser as manual (This isn't specific to the autoremove command, it does happen for them all, even in full-upgrade. It is just easier to see this way.) Something similar happens for packages which are put in Section: oldlibs in that they move their manual marking (if they have it) to the package(s) they depend on and mark themselves auto on upgrade to the version moving to oldlibs. As usual, both isn't really specific to apt but implemented in libapt, so aptitude and co should behave similar as long as the conditions are met. Disclaimer: I implemented both a long time ago (somewhat improving on similar existing behaviour… so even jessie is likely not effected, but I am too lazy to check and it doesn't really matter that much anyhow) That said, it is up to the maintainer to decide which section a package belongs to and more importantly if a package is really that central to the user experience of the metapackage that it must be a depends rather than recommends. (And yes, apt installs new recommends in upgrades since literal decades, so that is absolutely not a reason to use depends…) Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Project Improvements
Il 25/05/2022 10:33, Paul van der Vlis ha scritto: Op 23-05-2022 om 13:00 schreef Fabio Fantoni: Il 23/05/2022 01:42, Glauber Baldez ha scritto: Some considerations for project improvement: 1. Debian should already offer users a minimal installation mode similar to Ubuntu, without media players, games and office applications. 2. Debian should follow Doug Gwyn's words in stating that Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing smart things; the operating system must trust the user. Writing this, a big problem is not knowing how to differentiate the desktop environment from desktop applications, treating these factors as if they were the same thing. For example, the user cannot be prevented from removing the default web browser (desktop application) to replace it with another one of their choice as this breaks the desktop environment. Where's the freedom? I repeat again: desktop environment and desktop applications are not the same thing, so they shouldn't be treated as such either. Hi, thanks for your mail with suggestion to improve the project. I'm one maintainer of the cinnamon team, in the years I did some changes to make possible to have minimal installation of cinnamon. cinnamon (the package) without recommends is the very minimal. In some cases users had reported changes that had added unnecessary packages to the dependencies that I had then modified or removed and made some tests both on debian and ubuntu but unfortunately I can not do them often because they take a long time (both installation and quick functional tests) so report or advice from users are always useful. cinnamon-core and cinnamon-desktop-environment are 2 metapackage, the first for minimal desktop environment and second full. In the full one there are browser, media player and mail client are depends (libreoffice instead is already in recommends), one users recently required to remove browser and media player from depends but I added some alternative instead (in 5.2.2) thinking that are "essential software" for a full DE metapackage without recommends. I was wrong and I should move them to the recommends? Any reply/suggestion from other maintainers or users is appreciated. Sorry for my bad english. In my opinion it would be better to use recommends. I like to use a mail client myself, but many people want to use webmail these days for example. And many people don't use an IM client. you are right, I also have many customers who only use webmail (and I had underestimated them) and IM client installed also seem much less used recently Some people like to install a browser from outside Debian, like "Brave Browser" or a flatpack with the latest Firefox. in fact more and more users are using other browsers or browsers from flatpack (or others like snap) Such a meta-package is good to install many packages at once, but it would be nice to have the possibility to remove them individually. also this is right but it seems to me better that some packages still remain as dependencies by calculating other cases, for example as those who do a "lighter installation" without recommends, but that does not become "too small" to make the meta package not useful for that part of users I support many people with Debian, what I often see is that they remove a package, and then also the meta-package is removed. And later all dependencies of the meta-package are removed by accident. this is not in all cases, David Kalnischkies explained in his reply Just my 2 cents... thanks for your mail about cinnamon-desktop-environment for next version I moved browsers, mail clients, media players and instant messaging clients from depends to recomends, I also thought about the pdf viewer a bit but for now I think it's better that it stays in the dependencies. while the rest of the dependencies seem to me to be quite used, generally relevant and/or with too few users that I suppose they would like to remove to move them to recommends. any other advice, data or considerations are appreciated With regards, Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Project Improvements
Hello David and others, Op 25-05-2022 om 20:30 schreef David Kalnischkies: On Wed, May 25, 2022 at 10:33:22AM +0200, Paul van der Vlis wrote: I support many people with Debian, what I often see is that they remove a package, and then also the meta-package is removed. And later all dependencies of the meta-package are removed by accident. Not to rain on your parade, but those people should consider upgrading their Debian installations as since at least apt version 1.1 shipped before current old-old-stable (that is, they run at best Debian 8 jessie which is covered only by Extended LTS) apt actually marks dependencies of packages in section metapackages as manually installed if the metapackage is removed due to the removal of one of its dependencies – but doesn't if you decide to remove the metapackage explicitly. Realize that I do not always know why and how many packages are removed. But I see it happen, and not only at very old Debian versions. So, given: Package: mydesktop Depends: texteditor, browser Section: metapackages And mydesktop manual, the rest auto-installed: $ apt autoremove => nothing to be done $ apt autoremove mydesktop => removes also texteditor & browser $ apt autoremove texteditor => removes also mydesktop, but marks browser as manual Hmm, I did not know this. Very good! With regards, Paul (This isn't specific to the autoremove command, it does happen for them all, even in full-upgrade. It is just easier to see this way.) Something similar happens for packages which are put in Section: oldlibs in that they move their manual marking (if they have it) to the package(s) they depend on and mark themselves auto on upgrade to the version moving to oldlibs. As usual, both isn't really specific to apt but implemented in libapt, so aptitude and co should behave similar as long as the conditions are met. Disclaimer: I implemented both a long time ago (somewhat improving on similar existing behaviour… so even jessie is likely not effected, but I am too lazy to check and it doesn't really matter that much anyhow) That said, it is up to the maintainer to decide which section a package belongs to and more importantly if a package is really that central to the user experience of the metapackage that it must be a depends rather than recommends. > (And yes, apt installs new recommends in upgrades since literal decades, so that is absolutely not a reason to use depends…) Best regards David Kalnischkies -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl
Bug#1011667: ITP: mujoco -- A general purpose physics simulator.
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mujoco Version : 2.2.0 Upstream Author : DeepMind * URL : https://mujoco.org/ * License : Apache-2.0 Programming Lang: C Description : A general purpose physics simulator. I plan to maintain this under Debian Deep Learning Team.
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
On 5/24/22 21:34, Paul Gevers wrote: https://bugs.debian.org/1011268 (but apparently my first assumption was wrong and it's another bug, most likely Simon was right. Thanks for the link. I was quite puzzled this morning when I saw several removals messages. I guess I should just wait and hope that the removals don't actually happen. -Timo
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Le jeudi 26 mai 2022 à 09:32 +0300, Timo Lindfors a écrit : > > On 5/24/22 21:34, Paul Gevers wrote: > > https://bugs.debian.org/1011268 (but apparently my first assumption > > was wrong and it's another bug, most likely Simon was right. > > Thanks for the link. I was quite puzzled this morning when I saw > several removals messages. Several is an understatement... it's pouring in. Perhaps the autoremoval watch could *STOP* sending mails until the problem is fixed?! Cheers, J.Puydt
Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Would it be possible to manually remove this item from the list that generates autoremovals?This is creating an insane amount of noise and emails too.--Best,NileshOn 26/05/22, 12:11 pm Timo Lindfors wrote: On 5/24/22 21:34, Paul Gevers wrote: > https://bugs.debian.org/1011268 (but apparently my first assumption > was wrong and it's another bug, most likely Simon was right. Thanks for the link. I was quite puzzled this morning when I saw several removals messages. I guess I should just wait and hope that the removals don't actually happen. -Timo
Re: Project Improvements
On Wed, 25 May 2022 20:21:03 +0200, David Kalnischkies wrote: >apt actually marks dependencies >of packages in section metapackages as manually installed if the >metapackage is removed due to the removal of one of its dependencies >– but doesn't if you decide to remove the metapackage explicitly. That sounds nice and it's probably good to avoid accidental mass removals, but it makes the "manual" mark kind of a misnomer. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
