Am Mon, Sep 09, 2024 at 10:30:41AM GMT, schrieb Martin-Éric Racine: > In its current form, 'apt-get build-dep package' pulls all Build-Depends for > 'package' and marks them as manually installed, which means that they won't > be removed when later running 'apt-get --purge autoremove'.
I have to note that there is an option to disable the 'marks them as manual' part of that sentence so that a later autoremove would catch them: APT::Get::Build-Dep-Automatic which defaults to false, but can be set to true, e.g. with: -o APT::Get::Build-Dep-Automatic=true > It would therefore be desirable for apt-get to have a method for recursively > removing Build-Depends for 'package' either via an --option or via its own > command. Many packages can depend on rather generic things like say all KDE things depending on many dev packages or in some cases packages even build-depend on newer versions of packages like make or even of essentials like dpkg. As such, iterating the build-depends and "blindly" removing them all seems not that useful in many cases even if it probably works fine for most "normal" packages. I think what you are asking for is a way to remove the packages you installed in a previous build-dep action again. The option above sort-of does that if you set it. A more generic version would perhaps allow setting a user-defined flag on packages and querying for that flag later on. Another, perhaps better alternative, would be to "undo" the action. apt keeps a record of previous actions (/var/log/apt/history.log), but that is as far as that particular feature has been developed so far. We would need to parse the files and offer a UI to interact with this history, so you could tell apt to "undo" an entry from that history. I have put "undo" in quotes as this is not really the type of undo people know from a text editor: Package upgrades can not be undone (downgrades are unsupported), removed packages that can't be downloaded can't be (re)installed, purges are final and so on and so forth. So, the hard part about this might very well be finding the right name… apart from actually writing the code of course. So, to summarize, I can't see a lot of value in such a rather specific command given the options we have and those we might have in the future. Can you agree or do you have arguments/views I might have missed? As of now I would close this report in favour of the others. (I am relatively certain we have [at least one] open bugreports about all the things I mentioned here already, but I haven't checked) Best regards David Kalnischkies
signature.asc
Description: PGP signature
