ti 10. syysk. 2024 klo 20.36 Julian Andres Klode (j...@debian.org) kirjoitti: > > On Mon, Sep 09, 2024 at 11:44:09PM GMT, David Kalnischkies wrote: > > 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
That's not the same as an easy-to-remember apt-get --option or command. > > > 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 disagree. > > 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. > > I'm still going with undo, or rather `history undo` to match what users > already know from DNF. > > But yes, I did not have the time so far to implement it, and I need > to "finish" my new solver first :) In a broad sense, what we need is an apt-get --option or command that does something similar to what '--auto-remove purge' the metapackage created by devscript's 'mk-build-deps' does. Alternately, setting APT::Get::Build-Dep-Automatic default to true would accomplish the same. Basically, users should never end up stuck with a plethora of unwanted packages just because someone asked them to test whether a patch fixes the bug they reported and it required pulling a couple of GB of build-dependencies. Martin-Éric
