On Mon, Jan 30, 2023 at 12:03:14PM +0100, Guillem Jover wrote: > I checked the code and I find in apt-pkg/deb/dpkgpm.cc the > config variable pkgCacheGen::Protected being used, but I'm not sure I > understand how it is intended to be used? The code returns true for > "none" and "native" and when the "Important" flags is not-zero, but > «doc/examples/configure-index» also mentions an "all" value which > does not seem to be handled here? Shouldn't the "none" mean to return > false? pkgCacheGen::Essential is affecting the generation of the binary cache. Specifically, it tells the code to ignore the flag it parsed from the file in certain conditions and not mark the package essential in the cache – so that later apt code/runs believe the package is not marked essential at all. The code you found is preparing the command line for dpkg and that of course doesn't know what apt believes, so for certain values apt has to tell dpkg for all packages that dpkg is allowed to remove essential packages. - "all" is the default and keeps them all (aka ignores nothing). - "native" only marks :native or :all packages - "installed" only gives packages which are installed the flag - "none" ignores it for all, so no package is essential As we talk removals here we have to allow dpkg for all packages in the native/none case as we don't know if we have "forgotten" the flag for some packages. In the "all" case we haven't and in "installed" we haven't for anything which matters (= we aren't removing not installed packages after all), so those can rely on the info from the binary cache. But wait, you said pkgCacheGen::Protected… which intuitively should behave in the same way, but isn't handled in the same place essential is in apt-pkg/deb/deblistparser.cc. mhhhhh, I wrote the essential code (there, not the code you found actually) a long while ago but was not involved in the protected feature, so that could be intended in some way I don't foresee yet, but I suppose it was just forgotten. It is a rather esoteric feature after all. > If this is already supported by that option I'd request documentation > for it, or otherwise support for a similar option to control this > would be nice. Then a build-driver such as sbuild or pbuilder could > disable that option when and iff it knows it is driving the build > inside a discardable system. So, pkgCacheGen::Essential exists but isn't really documented except on a need-to-know basis and somewhere in the multiple-duplicates collection of bugs asking apt to behave a certain way with essentials. The reason is that it is hard to use: you need to provide it to the command which generates the binary cache, which is stored on disk for later commands to reuse as long as it remains valid & petty dangerous as apt will e.g. easily come to the conclusion that removing coreutils is acceptable because nothing really depends on it… While most users who demand such an option are more of the type: I want to remove this previously essential package (diff) which is now a transitional package (diffutils) but don't want to remove the old sources.list entry and I am really annoyed that apt reinstalls a package which is essential for an old release I have in my sources… those users are prime candidates for shooting themselves in the foot while demanding support as its an officially documented option. Anyway, you can get away with Build-Conflicts on Protected packages a lot easier with (partially) documented options: --allow-remove-essential -o APT::Get::Allow-Solver-Remove-Essential=true The first gets you past the error which used to be "Do as I say!" and the second is for the internal apt resolver (and relatively new¹). If another resolver is used you might need to use options specific to it (or not, if it doesn't care about the field). That isn't specific to build-dependencies either, its what you need in general while removing them (indirectly – the first is enough if you mention the package explicitly on the command line directly) in all cases. Yes, essential and protected are given the same treatment here. An equivalent just effecting protected seems not to exist. So, in summary, I think the solution to this bugreport might simple be to have the former flag also enable the later config option and perhaps mention in the documentation that this flag also effects protected. The semi-alternative would be to add also an --allow-remove-protected but I am not sure this is actually needed/a good idea. You have to be careful with either if your system is important and if your system isn't you are somewhat likely to provide both options together to apt anyhow just to be sure… Best regards David Kalnischkies ¹ 891efe3b201a104445ea723a3a5b9b434a78c364 (Wed Nov 17 2021)
Attachment:
signature.asc
Description: PGP signature