Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On Sat, 23 Dec 2023 at 18:43, Gioele Barabucci wrote: > > On 22/12/23 00:40, Daniel Kahn Gillmor wrote: > > If you're asking about using /etc/alternatives or something like that to > > provide some sort of generic swapping capability, or a dpkg Provides:, > > such that /usr/bin/gpg on some systems would point toward the > > "chameleon", i would want to see some significant archive-wide testing > > done before we even consider inflicting that on our normal users. > > While we are on the topic of alternatives, I hope to see the > maintscript-based /etc/alternatives paradigm deprecated in favor of the > package-based X-is-X paradigm introduced by `python-is-python3`. > > In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while > sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the > user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the > distro-wide preference expressed setting the appropriate Recommends in > gnupg or sequoia-chameleon-gnupg). > > Regards, Yes, that would be very nice, all those moving parts make the installation/upgrade processes so unnecessarily difficult and error prone. It's a maintenance nightmare that I'd be very happy to stop having to deal with anymore.
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On 17086 March 1977, Gioele Barabucci wrote: While we are on the topic of alternatives, I hope to see the maintscript-based /etc/alternatives paradigm deprecated in favor of the package-based X-is-X paradigm introduced by `python-is-python3`. In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the distro-wide preference expressed setting the appropriate Recommends in gnupg or sequoia-chameleon-gnupg). Ugh no, and have tons of near-empty packages for no good reason and also make local admins life harder. -- bye, Joerg
Bug#1059361: ITP: chr -- terminal-based text editor
Package: wnpp Severity: wishlist Owner: 'Christoph Hueffelmann' X-Debbugs-CC: debian-devel@lists.debian.org, textsh...@uchuujin.de *Package Name : chr Version : 0.1.75 Upstream Author : Christoph Hueffelmann , Martin Hostettler *URL : https://github.com/istoph/editor *License : BSL-1.0 *Description : terminal-based text editor A terminal based text editor. Keyboard shortcuts are similar to the default editors in Gnome, KDE and other desktop environments. This is to ease workflows alternating between GUIs and terminal. The look and feel is a blend of modern GUI editors and late 90s PC text mode editors (e.g. Turbo Vision based or edit.com) adapted to fit into terminal based workflows. It has been written from scratch using Tui Widget. It implements many features like: - selecting text by holding Shift - usable without a complicated config file - block selection - multi windows (overlapping, tiled, fullscreen) - text from full width windows can be copied from the terminal without window borders, scrollbars or additional spaces interfering. - syntax highlighting - undo/redo - display line numbers - soft-wrapping of long lines - interactive search and replace (with regular expression support) - go-to line (and column) command - support stdin buffers - drop down menus
Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On 22/12/23 00:40, Daniel Kahn Gillmor wrote: If you're asking about using /etc/alternatives or something like that to provide some sort of generic swapping capability, or a dpkg Provides:, such that /usr/bin/gpg on some systems would point toward the "chameleon", i would want to see some significant archive-wide testing done before we even consider inflicting that on our normal users. While we are on the topic of alternatives, I hope to see the maintscript-based /etc/alternatives paradigm deprecated in favor of the package-based X-is-X paradigm introduced by `python-is-python3`. In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the distro-wide preference expressed setting the appropriate Recommends in gnupg or sequoia-chameleon-gnupg). Regards, -- Gioele Barabucci
Re: /usr-move: Do we support upgrades without apt?
Helmut Grohne writes: > I incline to agreeing with the scenario you depict. This can reasonably > happen. I also think that David made a good case for it being unlikely > to manage oneself into the buggy situation that way. And then the > consequence is that you lost some possibly important files. If you ended > up fiddling with dpkg in a failed upgrade, would it be too much to ask > for running dpkg --verify? In the event you see missing files, you may > reinstall affected packages and thus have cured the symptoms for your > installation. > > Say we extended release-notes saying that you should dpkg --verify after > the upgrade and more so if you happened to use dpkg directly in the > process and review the output. Would that address your concern? Perhaps release-notes should suggest to run dpkg --verify after a dist-upgrade anyway - i assume it doesnt hurt to do so? Happy to suggest and edit text for release notes: i would want to know: - how do i know if the system is fine? i was assuming that it would output nothing if everything is fine, but that seems to be far from the case. I get huge amounts of output that is very hard to interpret, i assume it's showing a 'c' for every single changed conffile, and 'missing' where i deleted conffiles. But why are some lines contain question marks? we would need a lot of explanation here to make this useful for users (unfortunately, the dpkg man page is very confusing about this option, and doesnt have any of this, as far as i can understand) - if something went wrong: a) how do i know? would there be an obvious error message? do i need to check the exit status? b) what would i do?: reinstall some packages? reinstall the whole system? (maybe this should be in a bug against release-notes)
Bug#1059355: ITP: sway-contrib -- A collection of user-contributed scripts for sway
Package: wnpp Severity: wishlist Owner: Birger Schacht X-Debbugs-Cc: debian-devel@lists.debian.org, bir...@debian.org * Package name: sway-contrib Version : no version tag yet Upstream Contact: Sungjoon Moon * URL : https://github.com/OctopusET/sway-contrib * License : MIT Programming Lang: Python, Shell Description : A collection of user-contributed scripts for sway I plan to maintain this package in the swaywm-team.
