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'. 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. Thanks! Martin-Éric - -- Package-specific info: - -- (/etc/apt/preferences present, but not submitted) -- - -- (/etc/apt/preferences.d/funkyware.pref present, but not submitted) -- - -- (/etc/apt/sources.list present, but not submitted) -- - -- (/etc/apt/sources.list.d/funkyware.list present, but not submitted) -- - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.137 ii base-passwd 3.6.4 ii debian-archive-keyring 2023.4 ii gpgv 2.2.43-8+b1 ii libapt-pkg6.0t64 2.9.8 ii libc6 2.40-2 ii libgcc-s1 14.2.0-4 ii libgnutls30t64 3.8.6-2 ii libseccomp2 2.5.5-1+b1 ii libstdc++6 14.2.0-4 ii libsystemd0 256.5-2 Versions of packages apt recommends: ii ca-certificates 20240203 Versions of packages apt suggests: pn apt-doc <none> pn aptitude | synaptic | wajig <none> ii dpkg-dev 1.22.11 ii gnupg 2.2.43-8 ii powermgmt-base 1.37+nmu1 - -- no debconf information -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbepB4ACgkQrh+Cd8S0 17akZg//YW5jylntbh93X7dQpdRLMJsu9pihkpMbqi/QmmA40gRDI1LaTElEZjgS 7FA5Z+OIlAJehtNyzbPN7eLhSNdJItY0DNzu/8+kjqBlYE3N9bKcZYkwzTkrekCQ NCjru2ZSIeGX5ocICW6aFgVv3fKDOv3xtLv3VXSp+Y0lRjKPLM4Vqu2qadN5NxPl V5POI7EU5TFNWfwwkvCNTfJtanJ/xeNLatz/3CDjaTF6OHH/060AoCl0AATv9yRK XEebdN9ourJShZVuaM7SOZTHt9z65L65rdsMUpkX2zkb9yaXuEEUENTd5kDercn0 BMNnhvy8NptyEc7oxI4vM85c9jesKsjjG0S4OEw5+0etccsbVvzJ1UE61Mr8o599 /JJp4HgWO5vM/NW6oM1C9FiMnZjOJlEk6BbxzvFos25qYBKH9L7iajH/5CTKlUaG 5K/1T/UuwrpsvBslqGW/KYjqWT1RJEwZpormt0gALipwSC1xq0R6pYAQRHT63v5r 18qQJMz+7//fDyxwT66tD/PQMEYnPwabxpD8MURiywUuIltd3jmT2hRIWBqUc7u9 STTvsqMmAmHsxxaR5znHNHeeCa6USTAdy2ehMVzQhxXbtCJh1EV03pr3ZQk9uCTt 2fNziNeqmkBkfffYnAyUHJHdPYho0ENvk8F/YXlW+b4XM53qPtk= =dxxg -----END PGP SIGNATURE-----
If you do not already know about it, you might want to give a try to mk-build-deps from the devscripts package. Instead of directly installing the build dependencies it generates a local .deb package dependending on them, making them easy to install in a single command, and easy to uninstall (as they end up marked as automatically installed). https://manpages.debian.org/unstable/devscripts/mk-build-deps.1.html
Am Mon, Sep 09, 2024 at 10:30:41AM GMT, schrieb Martin-Éric Racine: 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 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
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 :)
ti 10. syysk. 2024 klo 20.36 Julian Andres Klode (jak@debian.org) kirjoitti: That's not the same as an easy-to-remember apt-get --option or command. I disagree. 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
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran, Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun. Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie für weitere Details.