Bug#1035413: ITP: node-codemirror-state -- Node.js module that implements the editor state for libjs-codemirror
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-codemirror-state Version : 6.2.0 Upstream Contact: Marijn Haverbeke * URL : https://github.com/codemirror/state * License : Expat Programming Lang: JavaScript Description : Node.js module that implements the editor state for libjs-codemirror node-codemirror-state (@codemirror/state) implements the editor state data structures for the CodeMirror code editor (libjs-codemirror). This package is a dependency of JupyterLab. It'll be maintained under JS Team umbrella
Re: DEP 17: Improve support for directory aliasing in dpkg
Hello, On Tue, 02 May 2023, Helmut Grohne wrote: > I think there is a caveat (whose severity I am unsure about): In order > to rely on this (and on DEP 17), we will likely have versioned > Pre-Depends on dpkg. Can we reasonably rule out the case where and old > dpkg is running, unpacking a fixed dpkg, configuring the fixed dpkg and > then unpacking an affected package still running the unfixed dpkg > process? I don't know APT well enough to answer that question but from my point of view it's perfectly acceptable to document in the release notes that you need to upgrade dpkg first. > I think the file loss problem is one sufficient reason to have the > moratorium. We didn't need other reasons once we knew this one. Now that > we look into dropping the moratorium, we need to ensure that there are > no reasons anymore and we learned that diversions are affected in a > non-trivial way. So even if we were to fix just the file loss problem, > the diversion problems would still be sufficient reason to keep the > moratorium unless they were also fixed by the approach. Here you need > both directions a) diverting a non-canonical location would have to > divert a canonical file and b) diverting a canonical location would have > to divert a non-canonical file. This is breaking the initial assumption. Are you sure that we need anything for diversions except some documented policy on how to deal with it? AFAIK the following sequence performs no filesystem changes and should be sufficient to move a diversion to its new location (I only consider the case of an upgrade, not of a new installation that should just work "normally" on the new location): dpkg-divert --package $package --remove /bin/foo --no-rename dpkg-divert --package $package --add /usr/bin/foo --divert /usr/bin/foo.diverted --no-rename The case of update-alternatives is likely more tricky. You already looked into it. That's a place where it will be harder to get things right without some changes. > In any case, this train of thought is definitely widening the solution > space. Thank you very much. You are welcome. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#1035427: ITP: node-react-toastify -- ReactJS module to add notifications
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-react-toastify Version : 9.1.2 Upstream Contact: https://github.com/fkhadra/react-toastify/issues * URL : https://github.com/fkhadra/react-toastify * License : Expat Programming Lang: JavaScript Description : ReactJS module to add notifications node-eact-Toastify allows one to add notifications to any ReactJS app with ease. Features: - easy to customize - RTL support - swipe to close, can choose swipe direction - animation of your choice - can display a react component inside the toast - onOpen/onClose hooks - can remove a toast programmatically - define behavior per toast - pause toast when the window loses focus - fancy progress bar to display the remaining time - possibility to update a toast - progress bar control - dark mode - ... This module is a dependency of JupyterLab and will be maintained under JS Team umbrella.
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Raphaël, On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote: > I don't know APT well enough to answer that question but from my point of > view it's perfectly acceptable to document in the release notes that you > need to upgrade dpkg first. Yes, this issue seems vaguely solvable one way or another. It also affects other approaches modifying dpkg in the very same way. > Are you sure that we need anything for diversions except some documented > policy on how to deal with it? Yes! There is a hard ordering constraint involved here. Failure to do so results in unpack errors and or file loss in much the same way. > AFAIK the following sequence performs no filesystem changes and should > be sufficient to move a diversion to its new location (I only consider the > case of an upgrade, not of a new installation that should just work > "normally" on the new location): > > dpkg-divert --package $package --remove /bin/foo --no-rename > dpkg-divert --package $package --add /usr/bin/foo --divert > /usr/bin/foo.diverted --no-rename This is insufficient. Either we modify dpkg to consider aliasing when managing diversions (i.e. Simon Richter's branch or DEP17) or there is a more complex ordering requirement involved: * We must not remove the aliased diversion (/bin/foo) before the diverted package has moved its files to the canonical location (/bin/foo -> /usr/bin/foo). * We must add the canonical diversion (/usr/bin/foo) before the diverted package update that moves its files to canonical locations can be unpacked. Say we currently have Package: diverter Version: 1 Files: /bin/foo preinst: diverts /bin/foo Package: diverted Version: 1 Files: /bin/foo We must first update the diverter. Package: diverter Version: 2 Files: /usr/bin/foo preinst: diverts both /bin/foo and /usr/bin/foo Since we divert both locations, diverter can now deal with an old diverted and a canonicalized diverted. Package: diverted Version: 2 Conflicts: diverter (<< 2~) Files: /usr/bin/foo At the time of unpacking the updated diverted, we must ensure that no diverter versioned 1 is unpacked. Breaks does not help here as it allows concurrent unpacks. Neither does Replaces since dpkg thinks that /bin/foo is different from /usr/bin/foo and thus no replacing happens. Package: diverter Version: 3 Conflicts: diverted (<< 2~) Files: /usr/bin/foo preinst: diverts /usr/bin/foo When unpacking the updated diverter, we must ensure that no diverted version 1 is unpacked. Again, Breaks and Replaces does not suffice. Therefore an upgrade from stable to nextstable containing both diverter and diverted must temporarily remove either package, which is known to annoy apt. What still applies here is that we can have usr-is-merged divert /usr/bin/dpkg-divert and have it automatically duplicate any possibly aliased diversion and then the diverter may Pre-Depends: usr-is-merged (>=...) to have its diversions duplicated. Of course, doing so will make usr-is-merged very hard to remove, but we have experience here from multiarch-support. Hope this clarifies. > The case of update-alternatives is likely more tricky. You already looked > into it. That's a place where it will be harder to get things right > without some changes. As detailed in https://lists.debian.org/debian-devel/2023/04/msg00169.html I believe that update-alternatives really are not tricky at all as long as we do not attempt to migrate them to canonical paths in any way. For instance, elvis-tiny needs to continue to name the editor alternative /bin/elvis-tiny even when it actually moves that file to /usr/bin. The reason that this does not hurt is that we never attempted to move alternatives (unlike regular files in packages). If we really want to migrate alternatives to canonical paths, we do get into the tricky area of preserving the user configuration and we also break custom scripts, ansible's community.general.alternatives, uses of puppet's alternatives modules and probably a lot more. And of course, we can always draw the diversion card and have usr-is-merged divert /usr/bin/update-alternatives to have it canonicalize paths as required to be able to migrate alternatives in a sane way (from a consumer point of view). Helmut
Re: DEP 17: Improve support for directory aliasing in dpkg
On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote: > On Tue, 02 May 2023, Helmut Grohne wrote: > > I think there is a caveat (whose severity I am unsure about): In order > > to rely on this (and on DEP 17), we will likely have versioned > > Pre-Depends on dpkg. Can we reasonably rule out the case where and old > > dpkg is running, unpacking a fixed dpkg, configuring the fixed dpkg and > > then unpacking an affected package still running the unfixed dpkg > > process? APT instructs dpkg to --unpack and to --configure in different calls, you can't mix and match those in the same call and apt never does the (combining) --install (not that it would really matter here). Also, dpkg is essential and as such has to work unpacked aka unpacking a fixed dpkg means that this fixed dpkg will (later) configure itself. Now, given dpkg is essential, it also means it gets the essential treatment from APT (by default) which means it will try to unpack it as soon as possible while trying to keep the time it remains unconfigured at a minimum. Give it a try, you usually see essential packages being interacted with first and in their own calls if you look close enough. That isn't an accident, the idea is that some random 'optional' package failing to install in some way should not leave you in a situation where essentials are in a state of limbo. If you increase the complexity of (pre-)requirements through APT will end up being forced to hand multiple packages in one go. Just pull up the last time you upgraded libc6: You will see a bunch of -dev packages and MultiArch siblings being unpacked alongside libc6 and libc-bin. You will only see those two being configured right after through. The dependencies will it is… so we might have to be a bit careful about the dependencies dpkg carries if such a route is taken. That said, there is always the 'stretch' horror story of APT installing all of KDE before touching dpkg because of the install-info transition… Although that was avoided before the release by removing from dpkg the Breaks leading us into this dark alley… (just to be sure: APT wasn't wrong, the dependencies weren't – but the idea to manually upgrade dpkg first to avoid some pitfalls was suggested which turned out to be wrong). Also, I wonder if we run into Pre-Depends loops and similar nasties given that the essential set is somewhat likely to pre-depend on things which use(d) to be in /lib which would in turn Pre-Depend on dpkg. (I haven't tried and memory is sketchy about those finer more complicated matters, but dpkg certainly can produce working orders for loops by inspecting which maintainer scripts exist or not, so upgrades involving those might or might not work. All bets are off which version of dpkg would be dealing with those through) > I don't know APT well enough to answer that question but from my point of > view it's perfectly acceptable to document in the release notes that you > need to upgrade dpkg first. Those never work in practice through. Nobody logs in on their buildd chroots and upgrades them "properly", we all just hope for the best. Even on systems we care more about people are regularity caught red handed by bothering support with questions whose answers are spelled out in detail in the release notes. Case in point: "Changed security archive layout" last time or "Non-free firmware moved to its own component in the archive" this time around… And those are easy to diagnose and fix. 'You "might" have some "random" files not present on disk. So your system might not even boot or spawns interdimensional portals. You better reinstall…' is not the type of thing you wanna here from support. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, On 03.05.23 19:19, Helmut Grohne wrote: What still applies here is that we can have usr-is-merged divert /usr/bin/dpkg-divert and have it automatically duplicate any possibly aliased diversion and then the diverter may Pre-Depends: usr-is-merged (>=...) to have its diversions duplicated. Of course, doing so will make usr-is-merged very hard to remove, but we have experience here from multiarch-support. For aliasing support in dpkg, that means we need a safe policy of dealing with diversions that conflict through aliasing that isn't "reject with error", because the magic dpkg-divert would always generate conflicts. One thing we need to check is whether diversions to the same target cause file conflicts -- I think they should. So if you divert /bin/foo -> /usr/bin/foo.dontdelete /usr/bin/foo -> /usr/bin/foo.dontdelete then a package containing /bin/foo and a package containing /usr/bin/foo now have a file conflict in dpkg. Not sure if that is a problem, or exactly the behaviour we want. Probably the latter, which would allow us to define a policy "if aliased paths are diverted, the diversion needs to match", which in turn would allow the conflict checker during alias registration to verify that the aliased diversions are not in conflict. The diverted dpkg-divert would probably generate extra register/unregister calls as soon as dpkg-divert itself is aliasing aware, but all that does is generate warning messages about existing diversions being added again, or nonexistent diversions being deleted -- these are harmless anyway, because maintainer scripts are supposed to be idempotent, and dpkg-divert supports that by not requiring scripts to check before they register/unregister. And of course, we can always draw the diversion card and have usr-is-merged divert /usr/bin/update-alternatives to have it canonicalize paths as required to be able to migrate alternatives in a sane way (from a consumer point of view). We get to draw this card exactly once, and any package that would need the same diversion would need to conflict with usr-is-merged, which would make it basically uninstallable. Simon
Bug#1035482: ITP: webext-svg-screenshots -- SVG screenshots browser extension
Package: wnpp Owner: deba...@debian.org Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: webext-svg-screenshots Version : 0.11.6 Upstream Author : Felix Becker * URL or Web page : https://github.com/felixfbecker/svg-screenshots/ * License : MIT Programming Lang: JavaScript Description : SVG screenshots browser extension Browser extension to take semantic, scalable, accessible screenshots of websites, as SVG - as simple as taking a PNG screenshot.
