Bug#990206: crowdsec: Program (and doc prompts to) access internal dpkg database
Control: found -1 1.4.2-1 Cyril Brulebois (2021-06-23): > I'm in touch with upstream, and various things should get improved in > their next major release regarding “configuration management” in a broad > sense (including the way assets are handled). The initial packaging was > an opportunity to discover a number of constraints/needs that weren't > necessarily clear or expressed in the first place (a shell wizard did > the job for source-based deployment). > > We tried to get something in shape before the bullseye freeze, and it > seemed we could speed things up a little by (ab)using the postinst in > this way; we expect to perform some heavy clean-up during the bookworm > release cycle, replacing a lot of (if not all of) Debian-specific code > with upstream things that are being developed, partly based on the > feedback gathered during initial packaging. This didn't happen in the 1.4.x series, and last I heard about it (a few weeks back), the plan was for 1.5.x to start featuring some assistant; but that's definitely post-bookworm. There were too many things to handle already, I haven't even tried to rework the internal dpkg database part… Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#990206: crowdsec: Program (and doc prompts to) access internal dpkg database
Hi Guillem, Here's some context for that. Guillem Jover (2021-06-23): > This package contains the «cscli» program, which directly accesses > the dpkg internal database, which seems gratuitous. > > The postinst is overloaded to act as some kind of helper that is then > called by Go code, or directly by the user (as prompted by the README). > Neither of the two functions involved share any other code with the rest > of the maintscript, and as it is this is not upstreamable. These should > be split into an external helper that gets called by both the maintscript > and the Go code. Or integrated directly in the Go CLI tool (but that > would be a bit more work). > > > This is a problem for several reasons, because even though the layout and > format of the dpkg database is administrator friendly, and it is expected > that those might need to mess with it, in case of emergency, this > “interface” does not extend to other programs besides the dpkg suite of > tools. The admindir can also be configured differently at dpkg build or > run-time. And finally, the contents and its format, might change in > the future. I'm in touch with upstream, and various things should get improved in their next major release regarding “configuration management” in a broad sense (including the way assets are handled). The initial packaging was an opportunity to discover a number of constraints/needs that weren't necessarily clear or expressed in the first place (a shell wizard did the job for source-based deployment). We tried to get something in shape before the bullseye freeze, and it seemed we could speed things up a little by (ab)using the postinst in this way; we expect to perform some heavy clean-up during the bookworm release cycle, replacing a lot of (if not all of) Debian-specific code with upstream things that are being developed, partly based on the feedback gathered during initial packaging. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#990206: crowdsec: Program (and doc prompts to) access internal dpkg database
Source: crowdsec Source-Version: 1.0.9-2 Severity: important User: debian-d...@lists.debian.org Usertags: dpkg-db-access-ctrl Hi! This package contains the «cscli» program, which directly accesses the dpkg internal database, which seems gratuitous. The postinst is overloaded to act as some kind of helper that is then called by Go code, or directly by the user (as prompted by the README). Neither of the two functions involved share any other code with the rest of the maintscript, and as it is this is not upstreamable. These should be split into an external helper that gets called by both the maintscript and the Go code. Or integrated directly in the Go CLI tool (but that would be a bit more work). This is a problem for several reasons, because even though the layout and format of the dpkg database is administrator friendly, and it is expected that those might need to mess with it, in case of emergency, this “interface” does not extend to other programs besides the dpkg suite of tools. The admindir can also be configured differently at dpkg build or run-time. And finally, the contents and its format, might change in the future. Thanks, Guillem
