Re: booststrapping /usr-merged systems
Hi Sven, On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote: > > Unfortunately, any > > external package that still ships stuff in /bin breaks this. In effect, > > any addon repository or old package can break your system. > > You lost me. We have converted /bin to a symlink already, have many > packages that ship files there and yet our systems do not break. Could > you please elaborate? I'm sorry. I see how I am mixing up use cases all the time. What is broken here is smooth upgrades (or package removal). Let me add detail. dpkg has two kinds of filesystem resources. These are owned objects and shared objects. A regular file usually is owned by one and only one package. A directory is often shared between multiple packages. A regular file can also be shared between multiple (Multi-Arch: same) instances of the same package. So whenever a package removes a shared object from a package (due to upgrading or removing the package), dpkg checks whether this shared object now is unreferenced. If that happens, it actually deletes it from the filesystem. So we kinda need to distinguish the actual filesystem view from the dpkg database view in this discussion. While the filesystem can now (since bookworm) be assumed to always have the symlinks, dpkg has a (shared) object there. It doesn't track the type yet (though Guillem is working[1] on that). Now we imagine a situation where we managed to get past this transition somehow and the end state is that no package in trixie ships /bin other than base-files, which ships it as a symlink. Or maybe we finished the transition by having no package ship /bin and we modified the bootstrap protocol to create the symlinks in another way. There is two use cases that are at risk now: * You have some old bookworm package around that still ships a file in /bin. You no longer need this package and remove it. Since this was the last package (on your system) to contain /bin (in data.tar), dpkg observes that /bin can go away and deletes your symlink. Boom. * You have some external repository that contains a package which still ships something in /bin. At some point the vendor got the message about moving files and moves them to /usr/bin and this - again - is when your /bin symlink vanishes during the package upgrade. So at this time, I think we basically have three ways of dealing with this: 1. Add a protective diversion for the affected locations (and keep that until forky at least). 2. Ship the affected symlinks as directories in some essential package until we are sure that no package ships these directories (even in external repositories). 3. Modify dpkg in some way to handle this case. I hope this made things more clear. Also note that this mail is purely concerned with dpkg package operations and entirely ignores the bootstrap use case. My takeaway here is that while I see the protective diversion as the "obviously superior solution", this clearly is not consensus at this time. It also means that when rewriting DEP 17, I need to spend quite a bit of text on rationale. Thank you. Helmut [1] https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
Re: Bug#1037250: ITP: fangfrisch -- Update and verify unofficial Clam Anti-Virus signatures
On Saturday, June 10, 2023 2:49:29 AM EDT Paul Wise wrote: > On Fri, 2023-06-09 at 12:46 +0200, Gürkan Myczko wrote: > >Description : Update and verify unofficial Clam Anti-Virus > > signatures This is a sibling of the Clam Anti-Virus freshclam utility. It > > allows downloading virus definition files that are not official ClamAV > > canon, e.g. from Sanesecurity, URLhaus and others. > > I was under the impression that ClamAV itself now has options to > download unofficial signatures, is that the case or was that removed? It does, but I think Fangfrisch is still a useful thing to have in Debian. Scott K signature.asc Description: This is a digitally signed message part.
Re: booststrapping /usr-merged systems
On 2023-06-10 10:39 +0200, Helmut Grohne wrote: > Hi Sven, > > On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote: >> > Unfortunately, any >> > external package that still ships stuff in /bin breaks this. In effect, >> > any addon repository or old package can break your system. >> >> You lost me. We have converted /bin to a symlink already, have many >> packages that ship files there and yet our systems do not break. Could >> you please elaborate? > > I'm sorry. I see how I am mixing up use cases all the time. What is > broken here is smooth upgrades (or package removal). Let me add detail. > > dpkg has two kinds of filesystem resources. These are owned objects and > shared objects. A regular file usually is owned by one and only one > package. A directory is often shared between multiple packages. A > regular file can also be shared between multiple (Multi-Arch: same) > instances of the same package. So whenever a package removes a shared > object from a package (due to upgrading or removing the package), dpkg > checks whether this shared object now is unreferenced. If that happens, > it actually deletes it from the filesystem. > > So we kinda need to distinguish the actual filesystem view from the dpkg > database view in this discussion. While the filesystem can now (since > bookworm) be assumed to always have the symlinks, dpkg has a (shared) > object there. It doesn't track the type yet (though Guillem is > working[1] on that). > > Now we imagine a situation where we managed to get past this transition > somehow and the end state is that no package in trixie ships /bin other > than base-files, which ships it as a symlink. That is what I would perceive as the goal. In this case, the /bin symlink is safe from being removed by dpkg since it is owned by a package. Or am I missing something? > Or maybe we finished the > transition by having no package ship /bin and we modified the bootstrap > protocol to create the symlinks in another way. I don not think this is possible, for the two reasons you gave below. > There is two use cases that are at risk now: > > * You have some old bookworm package around that still ships a file in >/bin. You no longer need this package and remove it. Since this was >the last package (on your system) to contain /bin (in data.tar), dpkg >observes that /bin can go away and deletes your symlink. Boom. > > * You have some external repository that contains a package which still >ships something in /bin. At some point the vendor got the message >about moving files and moves them to /usr/bin and this - again - is >when your /bin symlink vanishes during the package upgrade. Cheers, Sven
Re: booststrapping /usr-merged systems
On Sat, 10 Jun 2023 at 09:40, Helmut Grohne wrote: > My takeaway here is that while I see the protective diversion as the > "obviously superior solution", this clearly is not consensus at this > time. It also means that when rewriting DEP 17, I need to spend quite a > bit of text on rationale. Thank you. I would caution to avoid interpreting clarifying questions being asked as dissent. It's good to ask questions and clarify details about corner cases, but I wouldn't automatically write them down as disagreement. At least that's my reading of recent parts of this thread. Kind regards, Luca Boccassi
Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Package: wnpp Severity: wishlist Owner: Daniel Gröber X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-electronics-de...@alioth-lists.debian.net, d...@darkboxed.org * Package name: apycula Version : 0.8.1 Upstream Author : Pepijn de Vos * URL : https://pypi.org/project/Apycula * License : MIT Programming Lang: Python Description : Tools to generate Gowin FPGA bitstreams Project Apicula provides documentation and tools for the bitstream format used by Gowin GW1N series of FPGAs. We need this to enable nextpnr support for Gowin FPGAs in Debian. I'm intending to maintain this within the Debian Electronics Team like the similar fpga-icestorm package. I need a sponsor :) --Daniel
Re: Bug#1037250: ITP: fangfrisch -- Update and verify unofficial Clam Anti-Virus signatures
On Sat, 2023-06-10 at 09:50 -0400, Scott Kitterman wrote: > It does, but I think Fangfrisch is still a useful thing to have in Debian. I wonder if there is any tool that generates and/or contains the appropriate ClamAV configs for popular unofficial signatures, rather than manually downloading those signatures themselves. Perhaps Fangfrisch should become such a tool? Or is ClamAV upstream interested in such a tool/config? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
