Re: Override default post-install starting of services [was Return a Debian system to a pristine state]
On Sun 05 Jul 2020 at 20:12:36 (+), davidson wrote: > On Mon, 1 Jun 2020 David Wright wrote: > > On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote: > > > David Wright wrote: > > > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: > > [big snip] > > > > > > I, too, was surprised by some Debian features like its tendency > > > > > to start daemons with a vanilla configuration right after > > > > > installation. Still can't say I like this decision. > > > > > > > > This has been discussed in the past. > > Idly curious for links, in case anyone has them at hand. (Not asking > anyone to search for me, but not curious enough to search for everyone > else.) https://lists.debian.org/debian-user/2019/09/msg00895.html for example. The policy hasn't troubled me in the past. Cheers, David.
Re: Override default post-install starting of services [was Return a Debian system to a pristine state]
On Mon, 1 Jun 2020 David Wright wrote: On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote: David Wright wrote: On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: [big snip] I, too, was surprised by some Debian features like its tendency to start daemons with a vanilla configuration right after installation. Still can't say I like this decision. This has been discussed in the past. Idly curious for links, in case anyone has them at hand. (Not asking anyone to search for me, but not curious enough to search for everyone else.) [David Wright continued:] Using the term "vanilla" suggests that an ordinary upstream configuration is applied to the daemon, which is not true: the Debian developers apply what they consider are sensible secure defaults, designed to integrate with the distribution. This work is usually documented in changelog.Debian.gz or various READMEs. [Victor Sudakov asked:] Is the /usr/sbin/policy-rc.d method still the official supported one of disabling this behavior when it is not desirable? I have for a while assumed that this is what /etc/systemd/system-preset/*.preset files are for (on systems with systemd). Selective excerpts from systemd.preset(5): NAME systemd.preset - Service enablement presets SYNOPSIS /etc/systemd/system-preset/*.preset /run/systemd/system-preset/*.preset /lib/systemd/system-preset/*.preset /etc/systemd/user-preset/*.preset /run/systemd/user-preset/*.preset /usr/lib/systemd/user-preset/*.preset DESCRIPTION Preset files may be used to encode policy which units shall be enabled by default and which ones shall be disabled. They are read by "systemctl preset" (for more information see systemctl(1)) which uses this information to enable or disable a unit according to preset policy. "systemctl preset" is used by the post install scriptlets of RPM packages (or other OS package formats), to enable/disable specific units by default on package installation, enforcing distribution, spin or administrator preset policy. [With respect to that last bit about the post install scriptlets of packages, see my note at bottom.] This allows choosing a certain set of units to be enabled/disabled even before installing the actual package. For more information on the preset logic please have a look at the Presets document [at https://www.freedesktop.org/wiki/Software/systemd/Preset/ ]. [...] PRESET FILE FORMAT The preset files contain a list of directives consisting of either the word "enable" or "disable" followed by a space and a unit name (possibly with shell style wildcards), separated by newlines. [...] [...] Files in /etc/ override files with the same name in /usr/lib/ and /run/. Files in /run/ override files with the same name in /lib/. Packages should install their preset files in /lib/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the preset files installed by vendor packages. [...] EXAMPLES Example 1. Default to off # /lib/systemd/system-preset/99-default.preset disable * This disables all units. Due to the filename prefix "99-", it will be read last and hence can easily be overridden by spin or administrator preset policy. [...] Example 3. Administrator policy # /etc/systemd/system-preset/00-lennart.preset enable httpd.service enable sshd.service enable postfix.service disable * This enables three specific services and disables all others. This is useful for administrators to specifically select the units to enable, and disable all others. Due to the filename prefix "00-" it will be read early and override all other preset policy files. It's many years since I ran servers in what one might call "hostile" environments, (Myself I claim no experience whatsoever.) so the current situation suits me, and I don't keep up with discussions like those in https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html So others would have to comment here, after the discussion of resetting Windows has subsided. NOTE Regarding, "systemctl preset" is used by the post install scriptlets of RPM packages (or other OS package formats), to enable/disable specific units by default on package installation, enforcing distribution, spin or administrator preset policy. it seems we are not supposed to take that (weirdly distro-inappropriate) language too literally: $ for deb in /var/cache/apt/archives/*.deb ; \ > do dpkg-deb -I $deb preinst postinst 2>/dev/null ; \ > done | > grep -i 'preset' ; \ > if [ $? == 1 ] ; then echo SORRY BOSS ; fi SORRY BOSS Nonetheless, doing like so before issuing "apt-get install privoxy" # echo disable privoxy.service >> /etc/systemd/system-preset/05-privoxy-test.preset yields this installation message [...] Creating
Re: Return a Debian system to a pristine state
On Tue 09 Jun 2020 at 09:03:34 (+0300), Andrei POPESCU wrote: > On Lu, 08 iun 20, 14:32:29, David Wright wrote: > > > > I was impressed by apt-get's performance, probably because of dim > > memories of how dpkg would react on being asked to install ~2000 > > packages at once. The latter doesn't have the logic for sorting > > operations into a sequence that preserves an unbroken system. > > It's unclear to me what you meant by that. Perhaps I can clarify. Just as an experiment, I took a buster system that had a minimal installation of tasks "ssh server" and "standard utilities", plus: etckeeper git git-man patch rsync sudo apt-show-versions aptitude. I ran the attached file simultaneously requesting 271 packages, and thereby installing 1558. Everything was installed and configured correctly. I then reran the attached file but edited: install → purge, followed by apt-get --purge autoremove a couple of times. After all this, I was back at the original 350 packages that were present before I ran the attachment. Again, no problem. > Unless you use one of the --force options (at your own risk, of course) > dpkg will refuse actions that go against (Pre-)Depends, Conflicts and > Breaks. > > The difference between dpkg and apt in this regard is that dpkg acts > only on the set of packages it was provided. Having cleared the cache before I started the above, I now had the 1558 .deb files sitting in the cache, so to reinstall them I ran # dpkg -i -R -E /var/cache/apt/archives/. At the end of that process, the final messages from dpkg were: Errors were encountered while processing: /var/cache/apt/archives//fvwm-icons_20070101-4_all.deb /var/cache/apt/archives//gawk_1%3a4.2.1+dfsg-1_i386.deb /var/cache/apt/archives//libmotif-common_2.3.8-2_all.deb /var/cache/apt/archives//libxm4_2.3.8-2_i386.deb /var/cache/apt/archives//lilypond_2.19.81+really-2.18.2-13_i386.deb /var/cache/apt/archives//ntfs-3g_1%3a2017.3.23AR.3-3_i386.deb boot-info-script fig2dev testdisk xpdf Respectively, the 10 errors were: pre-dependency (4 off), file missing during pre-install, pre-dependency, gawk missing (2 off), ntfs-3g missing, libxm4 missing. In addition, this error message occurred during the run: systemctl preset failed on ModemManager.service: No such file or directory There was no problem setting up modemmanager when I was using apt-get. > User: dpkg, remove this package > dpkg: nope, this will break these other packages > User: apt, remove this package > apt: sure, in addition these other packages must be removed because > they depend on it > User: ok, go ahead > apt: dpkg, remove this set of packages > dpkg: sure, done > > User: dpkg, install this package > dpkg: nope, it depends on these other packages that are neither > installed nor were provided at the same time > User: apt, install this package > apt: sure, in addition these other packages must be downloaded and > installed to fulfill dependencies (and recommendations) > User: whatever, do it already > apt: ok, downloading... done > apt: dpkg, install this set of packages > dpkg: sure, done So—the "dim memories": Years ago, when I had to install duplicate systems on several machines, I would capture the cache from the first installation on a 1GB Jaz drive, and use it to install the others. (My systems were considerably smaller then.) One useful command when doing this wasdpkg --configure -a whenever dpkg got jammed up, followed by repeating the dpkg -i command (which explains using -E above). Cheers, David. apt-get -y install apt-file boot-info-script bootlogd cryptsetup-initramfs dosfstools eject flac gdisk gpm lame lynx mc mlocate normalize-audio mutt p7zip-full p7zip-rar lz4 putty putty-doc python-doc python3-doc python3-ly python3-dateutil python-reportlab dkms paps timidity rename scrot setcd smartmontools sox libsox-fmt-mp3 strace zip tnef unifont uudeview w3m wicd-curses xournal xpdf xzgv gpicview xzoom exim4 exim4-doc-html maildrop swaks fluid-soundfont-gm fluid-soundfont-gs fluidsynth pdftk-java texlive-luatex emacs emacs-common-non-dfsg printer-driver-cups-pdf vim vim-gtk hwdata hwinfo info pinfo inotify-tools inxi lshw di bbe jpeginfo alsa-utils alsaplayer-alsa alsamixergui alsa-tools-gui arandr evince font-manager gwaterfall fvwm fvwm-icons get-flash-videos swisswatch mbr menu mp3info resolvconf ntfs-3g ndiswrapper ndiswrapper-dkms ndiswrapper-source audacious-plugins audacity rosegarden firefox-esr-l10n-en-gb gnumeric tcpdump udisks2 vlock wakeonlan antiword anacron apt-doc aptitude-doc-en apt-rdepends at bash-doc bplay catdoc cdparanoia cdrskin curl dctrl-tools debian-handbook debian-history debian-policy debian-reference-en debian-timeline debian-keyring debootstrap deborphan debsums doc-base efibootmgr elinks gimp gparted parted-doc graphicsmagick grub-rescue-pc testdisk html2text htop inkscape imagemagick-6.q16
Re: Return a Debian system to a pristine state
On Lu, 08 iun 20, 14:32:29, David Wright wrote: > > I was impressed by apt-get's performance, probably because of dim > memories of how dpkg would react on being asked to install ~2000 > packages at once. The latter doesn't have the logic for sorting > operations into a sequence that preserves an unbroken system. It's unclear to me what you meant by that. Unless you use one of the --force options (at your own risk, of course) dpkg will refuse actions that go against (Pre-)Depends, Conflicts and Breaks. The difference between dpkg and apt in this regard is that dpkg acts only on the set of packages it was provided. User: dpkg, remove this package dpkg: nope, this will break these other packages User: apt, remove this package apt: sure, in addition these other packages must be removed because they depend on it User: ok, go ahead apt: dpkg, remove this set of packages dpkg: sure, done User: dpkg, install this package dpkg: nope, it depends on these other packages that are neither installed nor were provided at the same time User: apt, install this package apt: sure, in addition these other packages must be downloaded and installed to fulfill dependencies (and recommendations) User: whatever, do it already apt: ok, downloading... done apt: dpkg, install this set of packages dpkg: sure, done Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On Sat 06 Jun 2020 at 12:24:51 (+0300), Andrei POPESCU wrote: > On Jo, 04 iun 20, 09:32:48, David Wright wrote: > > On Sun 31 May 2020 at 18:43:46 (+0100), Michael Howard wrote: > > > > > > Well then it's not pristine, which is what the OP wanted. > > > > That begs the question of what pristine means, because it has never > > been defined even by the OP. Their closest attempt at a definition > > was the "first boot experience" but, unless you install a system as > > soon as a release is released, you can't return to that configuration > > without downgrading packages. That would make no sense at all, > > especially for someone with a serious concern about scanning for > > vulnerabilities. > > I don't recall anyone in the thread asking for exact versions at the > time of installation, just the same package set. > > This would also require exceptions for ABI changes (libfoo1 replaced by > libfoo2 or linux-image-x.y.z-1-amd64 replaced by > linux-image-x.y.z-2-amd64). These should be rare on stable + > stable-security and can be handled with the manual/auto installed > mechanism. I'm quite happy to accept that. As I run stable, I'm unlikely to run into complications concerning versions, but those running newer suites might have that problem where the functionality of a group of packages gets refactorised, so that some versions of A might break other versions of B. So the OP is happy with defining "pristine" as the original package set, and has realised that their life would have been made easier if they'd made a timely record. Or made a backup, in which case they could just grep /var/lib/dpkg/status. If they didn't, they might have to rely on the method I outlined to Marco (which The Wanderer corrected), using apt's history.log file. I did try out returning a system to its initial state, admittedly under favourable circumstances. After installing with the d-i, there were 531 packages installed. I ran my usual script that installs "all the rest" of my typical system, requesting 287 packages and, with their Depends and Recommends, installing about 2050. I then tac'd my script, edited all the installs to removes, and ran it. As it progressed, the proffered list of suggestions for autoremoval got longer and longer, so that by the time the script was finished, a simple autoremove command wiped out 885 packages. The system still had plenty of Recommends left installed, as one would expect, so I diff'd the list of post-installer packages with the current version to produce a 495-package purge command. (Because I had removed rather than purged packages, there were plenty of "rc"-status packages still installed, as well as the Recommends. That script removed virtually all the packages I had installed myself. I write "virtually" because, as I was doing all this casually, I had to reinstall aptitude twice (along with its Depends and Recommends) in order to run its "why" command, so I ended up with those extra packages still installed. I was impressed by apt-get's performance, probably because of dim memories of how dpkg would react on being asked to install ~2000 packages at once. The latter doesn't have the logic for sorting operations into a sequence that preserves an unbroken system. Cheers, David.
Re: Return a Debian system to a pristine state
On Fri 05 Jun 2020 at 13:04:08 (+0200), Marco Möller wrote: > On 04.06.20 21:46, The Wanderer wrote: > > On 2020-06-04 at 10:30, David Wright wrote: > > > On Mon 01 Jun 2020 at 12:15:02 (+0200), Marco Möller wrote: > > > > > > The short answer to this thread is that unfortunately Debian is > > > > not prepared with a simple solution for this simple task, but > > > > sophisticated workarounds are needed. > > > > > > As has been explained, it's not so simple, because *your* focus is > > > solely on the last apt command that you typed, whereas the package > > > management system is concerned with the whole system. Apt deals with > > > the system as a current state, and not as a chance sequence of > > > commands in reaching that state which must be reversible and > > > replayable, back and forth. > > > > > > When you install some packages and change your mind, just copy and > > > paste the line from /var/log/apt/history.log, replacing install with > > > remove (or purge). Sophisticated? > > > > Doesn't that fail to address the exact Recommends-related scenario which > > was his original complaint? Yes, sorry, I should have added the packages in the next line too (which involves a little more deletion of extraneous matter). [snipped example] > Thank You! You perfectly understood me and put it into clear words. > > > > He appears to argue (if not all that clearly) that the package manager > > should be tracking "install Recommends?" status on a per-package basis > > (i.e., probably in /var/lib/dpkg/status), such that only packages for > > which that flag is true will be considered as preventing a Recommended > > package from being autoremoved, even when Recommends are configured to > > be important. This would then let those two scenarios produce the same > > result, which could be argued to be valuable for "least surprise" > > consistency reasons. Well, it might be the least surprise for someone who has just installed a package that comes with a number of Recommends, and then removes it straight afterwards. But it's not least surprise for someone who's actually concerned about the current state of the whole package list, and the "top-level" package being removed has been installed for a longer period. > > Given the existence of the ability to configure Suggests as important, > > presumably an analogous flag would then need to be tracked per-package > > for Suggests as well. > > > > Structurally this doesn't even seem too difficult to design, at a naive > > outsider's glance, but how practical it would be to implement - both in > > terms of code, and in terms of the data that would have to be tracked > > and stored, as well as in terms of implementing both on top of the > > existing stored data which does not track this - may be quite another > > story. [snipped more complex example] > > I don't see as simple or straightforward a way to design around that > > problem. At that point, I think you would indeed have to start tracking > > the installation history in tree fashion, and I don't even know what the > > data structures or the necessary stored data for handling that elegantly > > or cleanly would need to look like. > > Because of this more complex scenario I suspected that not simply a > flag might suffice and therefore suggested that a tracking list would > be needed for registering exactly by WHICH other package a certain > package became recommended and drawn in. This list would get longer if > more than one package would have asked for the recommended, certain > package, and if this certain package specific list would result empty > again then this would flag it for allowed autoremoval. Of course the > certain package should not be an essential package like installed > during the intial Debian installation, but this requirement is what > the current apt is already considering for all packages anyway. > > After your post nicely confirmed that my idea was perfectly > understood, I will leave it here in the thread as it is. In the near > future I will organize my words, probably copying some of the > statements from this thread, and send it as a feature request to the > apt developers. I think there is not more which we can do as simple > users at this point. I don't think a reply loaded with "would"s confirms that it's perfectly understood at all. On Sat 06 Jun 2020 at 12:36:51 (+0300), Andrei POPESCU wrote: > > Something that should be much easier to implement would be for the > Debian Installer to save a list of installed packages and auto/manual > state (maybe also versions, just for good measure) after finishing the > installation. > > That would provide a good base to create a "remove everything I > installed since" script. Well, Marco is keen to file a severe bug; perhaps a wishlist item will suffice instead. Ironically, the d-i already stores a copy of the status file, but it's the one for the d-i itself, rather than the one for the /target system. For those who want this
Re: Return a Debian system to a pristine state
The Wanderer wrote: > but you might find some benefit from deborphan, > in the package of the same name. It basically reports the names of > installed packages which are not depended on by anything else. Thank you for the good advice! The first run of "deborphan -a" helped me recall a lot of "forgotten" software. Both deborphan and debfoster are similar to FreeBSD's pkg_cutleaves and can be very useful sometimes. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On 2020-06-06 at 06:29, Brian wrote: > On Fri 05 Jun 2020 at 12:01:32 -0400, The Wanderer wrote: > > [...] > >> Nowadays, my regular upgrade-against-testing routine - carried out >> at least weekly, if not daily - consists of the following (with >> adjustments to account for undesired installations, removals, bugs >> as reported by apt-listbugs, et cetera): >> >> $ apt-get update >> $ apt-get dist-upgrade >> $ apt-get autoremove >> $ apt-get remove $(deborphan) >> >> And if the deborphan step finds anything, I go back to the autoremove >> step, and repeat until neither of them has found anything. >> >> When I first started with deborphan, it took me somewhere between >> three and six repetitions of that pair of commands before I got to >> that point. Now, I can't even remember the last time deborphan >> found anything, because the system is already clean in this regard >> - but I still keep it up, just to make sure that doesn't change. > > An aside regarding deborphan: it finds packages that haven't any > packages depending on them. This may lead to the removal of a useful > package. For example, libsane-hpaio (installed without recommended > packages). As I have now discovered in response to your raising that: deborphan also supports two ways of listing packages which should be kept: the '-e' / '-exclude=' option (see the man page), and /var/lib/deborphan/keep. The former accepts a comma-separated list of package names, passed at launch time. The latter is a file with a newline-separated list of package names. If you list all explicitly-installed packages that you want to keep in the keepfile, then it might even be useful to run deborphan with '-a' / '--all-packages', which removes the "check only libs, et cetera" section restrictions. I may have to explore that, myself. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Return a Debian system to a pristine state
On Fri 05 Jun 2020 at 12:01:32 -0400, The Wanderer wrote: [...] > Nowadays, my regular upgrade-against-testing routine - carried out at > least weekly, if not daily - consists of the following (with adjustments > to account for undesired installations, removals, bugs as reported by > apt-listbugs, et cetera): > > $ apt-get update > $ apt-get dist-upgrade > $ apt-get autoremove > $ apt-get remove $(deborphan) > > And if the deborphan step finds anything, I go back to the autoremove > step, and repeat until neither of them has found anything. > > When I first started with deborphan, it took me somewhere between three > and six repetitions of that pair of commands before I got to that point. > Now, I can't even remember the last time deborphan found anything, > because the system is already clean in this regard - but I still keep it > up, just to make sure that doesn't change. An aside regarding deborphan: it finds packages that haven't any packages depending on them. This may lead to the removal of a useful package. For example, libsane-hpaio (installed without recommended packages). -- Brian.
Re: Return a Debian system to a pristine state
On Vi, 05 iun 20, 13:04:08, Marco Möller wrote: > > After your post nicely confirmed that my idea was perfectly understood, I > will leave it here in the thread as it is. In the near future I will > organize my words, probably copying some of the statements from this thread, > and send it as a feature request to the apt developers. I think there is not > more which we can do as simple users at this point. Something that should be much easier to implement would be for the Debian Installer to save a list of installed packages and auto/manual state (maybe also versions, just for good measure) after finishing the installation. That would provide a good base to create a "remove everything I installed since" script. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On Jo, 04 iun 20, 09:32:48, David Wright wrote: > On Sun 31 May 2020 at 18:43:46 (+0100), Michael Howard wrote: > > > > Well then it's not pristine, which is what the OP wanted. > > That begs the question of what pristine means, because it has never > been defined even by the OP. Their closest attempt at a definition > was the "first boot experience" but, unless you install a system as > soon as a release is released, you can't return to that configuration > without downgrading packages. That would make no sense at all, > especially for someone with a serious concern about scanning for > vulnerabilities. I don't recall anyone in the thread asking for exact versions at the time of installation, just the same package set. This would also require exceptions for ABI changes (libfoo1 replaced by libfoo2 or linux-image-x.y.z-1-amd64 replaced by linux-image-x.y.z-2-amd64). These should be rare on stable + stable-security and can be handled with the manual/auto installed mechanism. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On 2020-06-05 at 11:38, Victor Sudakov wrote: > John Hasler wrote: > >> David Wright writes: >> >>> That begs the question of what pristine means, because it has >>> never been defined even by the OP. >> >> I thought that we had learned that what he really wanted was to be >> able to identify packages that have not been used recently and >> remove them. > > What I originally wanted was based on the false assumption that > there are "system packages" and "user packages" in Debian, which > turned out not to be the case. > > The assumption was also formed partly after the FreeBSD experience, > and partly under the impression of Pamac, Mint Software Manager, App > Store, Google Play and other "software centers" which offer > productivity software install/uninstall in convenient form. > > The ability to identify packages that have not been used recently > and remove them, would be useful too. Defining "used" in terms which an algorithm could detect would be difficult here (Windows tries, or used to, but in my experience almost always gets it wrong), but you might find some benefit from deborphan, in the package of the same name. It basically reports the names of installed packages which are not depended on by anything else. On its face this wouldn't be useful, since nearly everything you've explicitly installed will usually qualify; what makes it useful is that it can (and, by default, does) limit its search to only specific sections of the Debian package archive, such as libs, oldlibs, and so forth. Since 'apt-get autoremove' already detects and removes packages which were installed only as dependencies and aren't depended on anymore, this is useful only for packages which got explicitly installed once upon a time and may have been forgotten about. I don't see such very often anymore, but when I first installed deborphan and tried it out, I found a surprising number of them. Nowadays, my regular upgrade-against-testing routine - carried out at least weekly, if not daily - consists of the following (with adjustments to account for undesired installations, removals, bugs as reported by apt-listbugs, et cetera): $ apt-get update $ apt-get dist-upgrade $ apt-get autoremove $ apt-get remove $(deborphan) And if the deborphan step finds anything, I go back to the autoremove step, and repeat until neither of them has found anything. When I first started with deborphan, it took me somewhere between three and six repetitions of that pair of commands before I got to that point. Now, I can't even remember the last time deborphan found anything, because the system is already clean in this regard - but I still keep it up, just to make sure that doesn't change. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Return a Debian system to a pristine state
John Hasler wrote: > David Wright writes: > > That begs the question of what pristine means, because it has never > > been defined even by the OP. > > I thought that we had learned that what he really wanted was to be able > to identify packages that have not been used recently and remove them. What I originally wanted was based on the false assumption that there are "system packages" and "user packages" in Debian, which turned out not to be the case. The assumption was also formed partly after the FreeBSD experience, and partly under the impression of Pamac, Mint Software Manager, App Store, Google Play and other "software centers" which offer productivity software install/uninstall in convenient form. The ability to identify packages that have not been used recently and remove them, would be useful too. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On 04.06.20 21:46, The Wanderer wrote: On 2020-06-04 at 10:30, David Wright wrote: On Mon 01 Jun 2020 at 12:15:02 (+0200), Marco Möller wrote: The short answer to this thread is that unfortunately Debian is not prepared with a simple solution for this simple task, but sophisticated workarounds are needed. As has been explained, it's not so simple, because *your* focus is solely on the last apt command that you typed, whereas the package management system is concerned with the whole system. Apt deals with the system as a current state, and not as a chance sequence of commands in reaching that state which must be reversible and replayable, back and forth. When you install some packages and change your mind, just copy and paste the line from /var/log/apt/history.log, replacing install with remove (or purge). Sophisticated? Doesn't that fail to address the exact Recommends-related scenario which was his original complaint? Say A and B both recommend C, and no other relevant packages do. Then: $ apt-get install --no-install-recommends A $ apt-get install B $ apt-get purge B $ apt-get autoremove As I recall and understand it, his original complaint is that this will then leave C installed, even though the context for the permission for it to be installed (the installation of B) no longer applies. (Similarly if you install A after installing B but before the autoremove.) By contrast, $ apt-get install B $ apt-get purge B $ apt-get autoremove $ apt-get install --no-install-recommends A will leave C not installed. Thank You! You perfectly understood me and put it into clear words. He appears to argue (if not all that clearly) that the package manager should be tracking "install Recommends?" status on a per-package basis (i.e., probably in /var/lib/dpkg/status), such that only packages for which that flag is true will be considered as preventing a Recommended package from being autoremoved, even when Recommends are configured to be important. This would then let those two scenarios produce the same result, which could be argued to be valuable for "least surprise" consistency reasons. Given the existence of the ability to configure Suggests as important, presumably an analogous flag would then need to be tracked per-package for Suggests as well. Structurally this doesn't even seem too difficult to design, at a naive outsider's glance, but how practical it would be to implement - both in terms of code, and in terms of the data that would have to be tracked and stored, as well as in terms of implementing both on top of the existing stored data which does not track this - may be quite another story. > It gets trickier again when you start to consider more complex scenarios, such as what happens when you change the "install Recommends?" status for an installed-as-Recommends package later on. When you install A with --no-install-recommends, C would clearly get that status set to "false". But when you install B without that switch, should C's "install Recommends?" status change to "true"? If the answer is yes, then the problem he was complaining about returns. But if the answer is no, then if you later remove A, C is now in a different status from what you'd have gotten if you installed B (and its Recommends) without having ever installed A in the first place. I don't see as simple or straightforward a way to design around that problem. At that point, I think you would indeed have to start tracking the installation history in tree fashion, and I don't even know what the data structures or the necessary stored data for handling that elegantly or cleanly would need to look like. Because of this more complex scenario I suspected that not simply a flag might suffice and therefore suggested that a tracking list would be needed for registering exactly by WHICH other package a certain package became recommended and drawn in. This list would get longer if more than one package would have asked for the recommended, certain package, and if this certain package specific list would result empty again then this would flag it for allowed autoremoval. Of course the certain package should not be an essential package like installed during the intial Debian installation, but this requirement is what the current apt is already considering for all packages anyway. After your post nicely confirmed that my idea was perfectly understood, I will leave it here in the thread as it is. In the near future I will organize my words, probably copying some of the statements from this thread, and send it as a feature request to the apt developers. I think there is not more which we can do as simple users at this point. Best wishes, Marco!
Re: Return a Debian system to a pristine state
David Wright writes: > That begs the question of what pristine means, because it has never > been defined even by the OP. I thought that we had learned that what he really wanted was to be able to identify packages that have not been used recently and remove them. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Return a Debian system to a pristine state
On 2020-06-04 at 10:30, David Wright wrote: > On Mon 01 Jun 2020 at 12:15:02 (+0200), Marco Möller wrote: >> The short answer to this thread is that unfortunately Debian is >> not prepared with a simple solution for this simple task, but >> sophisticated workarounds are needed. > > As has been explained, it's not so simple, because *your* focus is > solely on the last apt command that you typed, whereas the package > management system is concerned with the whole system. Apt deals with > the system as a current state, and not as a chance sequence of > commands in reaching that state which must be reversible and > replayable, back and forth. > > When you install some packages and change your mind, just copy and > paste the line from /var/log/apt/history.log, replacing install with > remove (or purge). Sophisticated? Doesn't that fail to address the exact Recommends-related scenario which was his original complaint? Say A and B both recommend C, and no other relevant packages do. Then: $ apt-get install --no-install-recommends A $ apt-get install B $ apt-get purge B $ apt-get autoremove As I recall and understand it, his original complaint is that this will then leave C installed, even though the context for the permission for it to be installed (the installation of B) no longer applies. (Similarly if you install A after installing B but before the autoremove.) By contrast, $ apt-get install B $ apt-get purge B $ apt-get autoremove $ apt-get install --no-install-recommends A will leave C not installed. He appears to argue (if not all that clearly) that the package manager should be tracking "install Recommends?" status on a per-package basis (i.e., probably in /var/lib/dpkg/status), such that only packages for which that flag is true will be considered as preventing a Recommended package from being autoremoved, even when Recommends are configured to be important. This would then let those two scenarios produce the same result, which could be argued to be valuable for "least surprise" consistency reasons. Given the existence of the ability to configure Suggests as important, presumably an analogous flag would then need to be tracked per-package for Suggests as well. Structurally this doesn't even seem too difficult to design, at a naive outsider's glance, but how practical it would be to implement - both in terms of code, and in terms of the data that would have to be tracked and stored, as well as in terms of implementing both on top of the existing stored data which does not track this - may be quite another story. It gets trickier again when you start to consider more complex scenarios, such as what happens when you change the "install Recommends?" status for an installed-as-Recommends package later on. When you install A with --no-install-recommends, C would clearly get that status set to "false". But when you install B without that switch, should C's "install Recommends?" status change to "true"? If the answer is yes, then the problem he was complaining about returns. But if the answer is no, then if you later remove A, C is now in a different status from what you'd have gotten if you installed B (and its Recommends) without having ever installed A in the first place. I don't see as simple or straightforward a way to design around that problem. At that point, I think you would indeed have to start tracking the installation history in tree fashion, and I don't even know what the data structures or the necessary stored data for handling that elegantly or cleanly would need to look like. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Return a Debian system to a pristine state
On 6/4/20 02:45, Sijmen J. Mulder wrote: > Marco Möller wrote: >>> In the fairly large number of posts in this thread I don't recall seeing >>> file system snapshots suggested. My current preference is ZFS, which I >>> know from experience to be up to what I understand to be the goal here. >> >> (...) >> I understand the OP to be in search for the uncomplicated removal of >> installed packages considering package installation dates. >> A fs snaphot tool is likely to return to a general system state which >> would include also the return of the user data and system configurations >> to a point of time in the past, instead of only treating package >> installs. And if having to prepare sophisticated steps like requiring >> special partitioning schemes, then this wouldn't be uncomplicated anymore. Debian root on ZFS installation is non-standard (where the standard is the Debian installer). It is more complicated than the standard install, but instructions at https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html describe adequately how to do it using a Debian Live CD. I used an earlier, slightly less polished, version for five or six installs and found it satisfactory. It is a hands-on command line install using the shell in a terminal, but most of the commands can be copied and pasted from the documentation with only minor changes. >> Agreed, but at risk of going a bit off track, I didn't find this to be > a problem in practice on ZFS native systems like SmartOS. Separate > volume on /usr/pkg, snapshot, done. Of course the situation in Debian > is a bit different. > > Sijmen >
Re: Return a Debian system to a pristine state
On Sun 31 May 2020 at 18:43:46 (+0100), Michael Howard wrote: > On 31/05/2020 15:59, Thomas Schmitt wrote: > > Michael Howard wrote: > > > With linux (debian) you could just create an image (using dd for example) > > > of > > > the drive in order to restore it at a later date. > > If a backup shall have a chance to be absolutely safe it must be done > > while the backuped filesystems are unmounted or mounted read-only. > > Obviously. > > > This implies that it must be done by an operating system that it not > > using these to-be-backuped filesystems for its own needs. Debian Live > > comes to my mind. > As good a choice as any. > > Do we have a feature to get a list of installed packages and to later > > use it for re-installation ? > > > > I normally need weeks to get everything installed on my next machine. > > In the beginning it is easy to choose the big chunks. But the previous > > machine is then old as stone and can hardly serve for the fine tuning. > > So i need to find out what's still missing and install on demand. > > > Well then it's not pristine, which is what the OP wanted. That begs the question of what pristine means, because it has never been defined even by the OP. Their closest attempt at a definition was the "first boot experience" but, unless you install a system as soon as a release is released, you can't return to that configuration without downgrading packages. That would make no sense at all, especially for someone with a serious concern about scanning for vulnerabilities. And why would one decide that the only systems that could be considered as "pristine" are those where the "privileged" list of installed packages corresponds to one of the arbitrary selections chosen by the installer's developers. In addition, when the "privileged" packages are reverted to their original configuration at first boot, it's potentially undoing a great deal of the sysadmin's work, which then has to be re-done. Where's the sense in that. And if you *don't* revert the configuration, you could end up with a non-functional system, because the final production configuration might depend on the "unprivileged" packages that have just been uninstalled. Cheers, David.
Re: Return a Debian system to a pristine state
On Mon 01 Jun 2020 at 12:15:02 (+0200), Marco Möller wrote: > On 01.06.20 04:41, emetib wrote: > > this has been an interesting topic, so what the hell, here's my two cents. > > > > for my vm's, i have a list off packages that i install as soon as the > > minimum/base install and reboot is done. 4 vm's, testing, stable, centos7, > > opensuse. i have no gui's on these only cli, just need to know how to > > configure things for other os's than debian and it becomes a simple cut and > > paste to get a system to be at what i need. I keep such a list as a sequence of apt-get -y install … commands, but this is preceded by an update/upgrade, installation of etckeeper, git and git-man (and commit), and one or two chmod/chgrp commands in my favour. Those few install commands omit the -y. I keep the script up-to-date when I add significant packages, and it saves a lot of time because I presently run five systems with near identical configurations. If I were to rerun it, it would just chunder away, adding anything that's new. The last packages in the script are apt-listbugs and needrestart; last because they would keep interrupting the process with their demands for a response. Finally, I purge the american dictionaries, and rerun update to fill the cache for apt-file. > > have a home partition, not just a home dir, and back it up often with a > > timestamp on it, and do a --get-selections and dump it to a file that you > > back up also. also doing that is an easy way to compare what was installed > > and what is now installed. I consider a /home partition vital, and it's encrypted. along with swap (random key). I prefer to work with "top-level" packages rather than --[gs]et-selections, as the latter involves >2000 packages, many of them entirely uninteresting/unrecognisable. > > keep sensitive config files in a spot that you know is going to be backed > > up or on your home partition so they aren't overwritten with a new install. I keep copies of any files I have changed in directories called /home/system---/ where the filenames are mangled thus: ¬etc¬default¬console-setup Having a flat directory makes it easy to update, check, and compare systems with one-line commands. > > there was a suggestion about using a live distro to make a back up right > > away, never done it before, yet this is a great idea. Because I always have two root filesystems on the disk, I just use the other system. But I don't make a habit of backing up the whole system, only my configuration of it, plus a selection of log files. > > i believe that someone (smarter than me) could write a simple script to put > > all user installed programs into a file and then reinstall them after a > > full-reinstall. Just put the commands that you type into a file like the above, and bash it. Go from there. > > i.e. > > bash_install_script.sh > > check if su > > add package to list > > continue with the install > > This is almost exactly what I am also doing. > > The problem remains to simply remove a couple of packages without > having to go for a full blown system reinstall and all the necessary > requirements for organizing it well. This is a false dichotomy. There's no problem with removing a couple of packages; you just misunderstood the meaning of --no-install-recommends and the way packages interact, and then expected apt to automatically bend to your will and fix the mistake for you. > As there is a package manager, it > is obviously a straight forward logic to expect it to do this job, > because this is exactly what a package manager is expected to manage. > All other suggestions which have been brought up in the thread are > workarounds for filling the gap where the package manager is not full > featured. That's how computer systems work. People write software that does what is considered sensible, and others build upon this by writing scripts, rather than posting that the software has a severe bug and they can't believe that it doesn't do what they want it to do in the way they want it. > The short answer to this thread is that unfortunately Debian is not > prepared with a simple solution for this simple task, but > sophisticated workarounds are needed. As has been explained, it's not so simple, because *your* focus is solely on the last apt command that you typed, whereas the package management system is concerned with the whole system. Apt deals with the system as a current state, and not as a chance sequence of commands in reaching that state which must be reversible and replayable, back and forth. When you install some packages and change your mind, just copy and paste the line from /var/log/apt/history.log, replacing install with remove (or purge). Sophisticated? Cheers, David.
Re: Return a Debian system to a pristine state
Marco Möller wrote: > > In the fairly large number of posts in this thread I don't recall seeing > > file system snapshots suggested. My current preference is ZFS, which I > > know from experience to be up to what I understand to be the goal here. > > (...) > I understand the OP to be in search for the uncomplicated removal of > installed packages considering package installation dates. > A fs snaphot tool is likely to return to a general system state which > would include also the return of the user data and system configurations > to a point of time in the past, instead of only treating package > installs. And if having to prepare sophisticated steps like requiring > special partitioning schemes, then this wouldn't be uncomplicated anymore. Agreed, but at risk of going a bit off track, I didn't find this to be a problem in practice on ZFS native systems like SmartOS. Separate volume on /usr/pkg, snapshot, done. Of course the situation in Debian is a bit different. Sijmen
Re: Return a Debian system to a pristine state
On Tue 02 Jun 2020 at 11:03:48 (+0700), Victor Sudakov wrote: > David Wright wrote: > > On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote: > > > David Wright wrote: > > > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: > > > > > David Wright wrote: > > > > > > Finally, pkg delete -a sounds like something from the abattoir, > > > > > > rather than anything you'd do to a pet (to use your analogy). > > > > > > > > > > It's not as terrible as it sounds ;-) It's more from a vet clinic than > > > > > from a slaughterhouse. You don't lose configs, you don't lose network > > > > > connectivity or remote access during this procedure. You can save a > > > > > list > > > > > of installed packages before deleting them, and reinstall only those > > > > > you > > > > > know you need. > > > > > > > > > > Unfortunately, the FreeBSD package system is not as mature as DEB or > > > > > RPM, therefore until very recently the "pkg delete -a" procedure has > > > > > been required to get rid of the dependencey hell. > > > > > > > > OK, that sounds more like what people do on Windows systems, where > > > > there's a reset option, except that on Windows you can, ISTR, lose > > > > all your own files if they're under C:. > > > > > > Since what version does Windows have a reset option? > > > > No idea. The last version of Windows that I used was IIRC 3.11. > > I parted company when W95 came with "DOS" 7 rather than a > > successor to DOS 6.22. > > Ah, I thought you knew something I did not. No chance of that. > Then no, Windows still does > not have a reset option. I don't know how you define "reset option". I was just employing those words with their generally accepted meanings: reset means "set again", in the sense of "restore", and option means "through choice". You obviously have a more technical meaning in mind. > > > For dozens of > > > years, literally, Windows has been notorious for leftovers of removed > > > programs remaining in the "base system" and causing unexpected effects. > > > There were even commercial products on the market to purge those > > > leftovers. > > > > You're way ahead of me on Windows, then. I just know what I've seen, > > and what I saw was this: > > > > Chapter 3. Lenovo OneKey Recovery system > > The Lenovo OneKey Recovery system is software designed to back up and > > restore your computer. You can use it to restore the system partition to > > its > > Such things are present in some laptops, but they are not part of > Windows per se, they are developed by equipment manufacturers. Usually > they just extract an OEM image of Windows from some recovery partition > in case a user renders his/her system unbootable, as was verbosely > quoted below. Well, what you are asking for in your subject line concerns Debian, so I chose to make this analogy in quoting that source: an OS is part of a computer system, Windows is part of the Lenovo system purchased, Linux is part of a Debian system. What counts as a "reset option" for Linux, as opposed to Debian? > [dd] > > > > > FreeBSD is different in this respect. No part of third-party software > > > ever gets into the base system (unless you install something manually > > > and incorrectly). > > > > This has already been pointed out, that Debian's installed system is > > an individual outcome, not some sort of mandated selection. > > > > > And of course you don't lose any user data if you run > > > "pkg delete -a" > > > > I didn't know we were discussing user data at all. > > Apparently we were. Let me quote your own words among others: > "... ISTR, lose all your own files if they're under C:" That partial quotation omits the opening words. The paragraph was: OK, that sounds more like what people do on Windows systems, where there's a reset option, except that on Windows you can, ISTR, lose all your own files if they're under C:." The example of Windows was brought up in response to your mentioning "dependency hell", something I remember well when my institution upgraded their Windows users to W95. And with Windows, you don't "own" C:, even though many users leave their own files there. In Debian, you "own" /home, which is why there's no need to discuss it here. (Whether you decide to wipe the filesystem containing /home is up to you, of course.) > > > > Debian doesn't work that way: you can remove packages from the system > > > > at will in a controlled manner. Isn't that what sysadmins do? > > > > > > Well, I was not feeling particulary sysadmin-ish about the desktop > > > system I wanted to cleanup. > > > > How you feel about it can't alter the fact that reverting a system by > > removing packages is a sysadmin-ish process: you administering the > > system. > > This is more of a terminological question. As is the definition of "pristine state" for a Debian system. > Is a user installing or > removing GIMP of FireFox really administering a system? Some > administrative tasks are
Re: Return a Debian system to a pristine state
Victor Sudakov wrote: > David Wright wrote: > > > > How you feel about it can't alter the fact that reverting a system by > > removing packages is a sysadmin-ish process: you administering the > > system. > > This is more of a terminological question. Is a user installing or > removing GIMP of FireFox really administering a system? Some > administrative tasks are easy enough to be performed by users, and maybe > (just maybe) the removal of extra software should be easy enough > to be user-serviceable (i.e. not carry the risk of killing the system > itself, or require sysadmin knowledge and reading of manual pages). Quoting myself: The essence of the UNIX philosophy is not "make small utilities that can be fitted together with pipes" but to assume that at any moment, a user might decide to be a developer or a sysadmin and should have the tools to do that. The problems of UNIX generally come from assuming either that users are never devs and sysadmins, or that all users are devs and sysadmins. -dsr-
Re: Return a Debian system to a pristine state
On Ma, 02 iun 20, 11:03:48, Victor Sudakov wrote: > David Wright wrote: > > > > It's many years since I ran servers in what one might call "hostile" > > environments, so the current situation suits me, and I don't keep up > > with discussions like those in > > https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html > > It's an interesting development, I'm positively interested. Do you know > if I can somehow subscribe to see what's happening in this direction? The Debian Package Tracker[1] supports "subscribing" to source packages, to receive various updates about the package (bugs, uploads, testing migration, etc.). Most Debian packages have their source code on Salsa[2], which is Debian's Gitlab instance. Since policy-rcd-declarative is a "native" package, that is also the upstream source. [1] https://tracker.debian.org [2] https://salsa.debian.org Hope this helps, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
David Wright wrote: > On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote: > > David Wright wrote: > > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: > > > > David Wright wrote: > > > > > Finally, pkg delete -a sounds like something from the abattoir, > > > > > rather than anything you'd do to a pet (to use your analogy). > > > > > > > > It's not as terrible as it sounds ;-) It's more from a vet clinic than > > > > from a slaughterhouse. You don't lose configs, you don't lose network > > > > connectivity or remote access during this procedure. You can save a list > > > > of installed packages before deleting them, and reinstall only those you > > > > know you need. > > > > > > > > Unfortunately, the FreeBSD package system is not as mature as DEB or > > > > RPM, therefore until very recently the "pkg delete -a" procedure has > > > > been required to get rid of the dependencey hell. > > > > > > OK, that sounds more like what people do on Windows systems, where > > > there's a reset option, except that on Windows you can, ISTR, lose > > > all your own files if they're under C:. > > > > Since what version does Windows have a reset option? > > No idea. The last version of Windows that I used was IIRC 3.11. > I parted company when W95 came with "DOS" 7 rather than a > successor to DOS 6.22. Ah, I thought you knew something I did not. Then no, Windows still does not have a reset option. > > For dozens of > > years, literally, Windows has been notorious for leftovers of removed > > programs remaining in the "base system" and causing unexpected effects. > > There were even commercial products on the market to purge those leftovers. > > You're way ahead of me on Windows, then. I just know what I've seen, > and what I saw was this: > > Chapter 3. Lenovo OneKey Recovery system > The Lenovo OneKey Recovery system is software designed to back up and > restore your computer. You can use it to restore the system partition to its Such things are present in some laptops, but they are not part of Windows per se, they are developed by equipment manufacturers. Usually they just extract an OEM image of Windows from some recovery partition in case a user renders his/her system unbootable, as was verbosely quoted below. [dd] > > > FreeBSD is different in this respect. No part of third-party software > > ever gets into the base system (unless you install something manually > > and incorrectly). > > This has already been pointed out, that Debian's installed system is > an individual outcome, not some sort of mandated selection. > > > And of course you don't lose any user data if you run > > "pkg delete -a" > > I didn't know we were discussing user data at all. Apparently we were. Let me quote your own words among others: "... ISTR, lose all your own files if they're under C:" > > > > Debian doesn't work that way: you can remove packages from the system > > > at will in a controlled manner. Isn't that what sysadmins do? > > > > Well, I was not feeling particulary sysadmin-ish about the desktop > > system I wanted to cleanup. > > How you feel about it can't alter the fact that reverting a system by > removing packages is a sysadmin-ish process: you administering the > system. This is more of a terminological question. Is a user installing or removing GIMP of FireFox really administering a system? Some administrative tasks are easy enough to be performed by users, and maybe (just maybe) the removal of extra software should be easy enough to be user-serviceable (i.e. not carry the risk of killing the system itself, or require sysadmin knowledge and reading of manual pages). [dd] > > > > Is the /usr/sbin/policy-rc.d method still the official supported one of > > disabling this behavior when it is not desirable? > > It's many years since I ran servers in what one might call "hostile" > environments, so the current situation suits me, and I don't keep up > with discussions like those in > https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html It's an interesting development, I'm positively interested. Do you know if I can somehow subscribe to see what's happening in this direction? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On 6/1/20 00:28, Andrei POPESCU wrote: >On Du, 31 mai 20, 20:52:06, Tom Dial wrote: >> >> Moreover, ZFS is not DFSG and GPL compliant, and quite a few >> users would avoid it because of that. > >ZFS is licensed under the CDDL[1], which is both free (as in freedom) >and DFGS *compliant*. > >It is also *incompatible* with the GPL, which means distributing a Linux >kernel (GPL) including the ZFS modules is possibly illegal[2]. I knew this, but overlooked that the relevant packages are in contrib, presumably indicating their DFSG compliance. Thank you for the correction. TDD > >End users however are well within their rights (freedom 0 and 1)[3] to >use this combination, as long as they don't share it with anyone else >(freedoms 3 and 4)[3]. > >[1] https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License >[2] As far as I know this was never tested in court >[3] https://en.wikipedia.org/wiki/The_Free_Software_Definition > >Hope this explains, >Andrei >-- >http://wiki.debian.org/FAQsFromDebianUser
Re: Return a Debian system to a pristine state
On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote: > David Wright wrote: > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: > > > David Wright wrote: > > > > Finally, pkg delete -a sounds like something from the abattoir, > > > > rather than anything you'd do to a pet (to use your analogy). > > > > > > It's not as terrible as it sounds ;-) It's more from a vet clinic than > > > from a slaughterhouse. You don't lose configs, you don't lose network > > > connectivity or remote access during this procedure. You can save a list > > > of installed packages before deleting them, and reinstall only those you > > > know you need. > > > > > > Unfortunately, the FreeBSD package system is not as mature as DEB or > > > RPM, therefore until very recently the "pkg delete -a" procedure has > > > been required to get rid of the dependencey hell. > > > > OK, that sounds more like what people do on Windows systems, where > > there's a reset option, except that on Windows you can, ISTR, lose > > all your own files if they're under C:. > > Since what version does Windows have a reset option? No idea. The last version of Windows that I used was IIRC 3.11. I parted company when W95 came with "DOS" 7 rather than a successor to DOS 6.22. > For dozens of > years, literally, Windows has been notorious for leftovers of removed > programs remaining in the "base system" and causing unexpected effects. > There were even commercial products on the market to purge those leftovers. You're way ahead of me on Windows, then. I just know what I've seen, and what I saw was this: Chapter 3. Lenovo OneKey Recovery system The Lenovo OneKey Recovery system is software designed to back up and restore your computer. You can use it to restore the system partition to its original status in case of a system failure. You can also create user backups for easy restoration as required. Note: To utilize the features of the OneKey Recovery system, your hard disk already includes a hidden partition by default to store the system image file and the OneKey Recovery system program files. This default partition is hidden for security reasons, which explains why the available disk space is less than the stated capacity. · Backing up the system partition You can back up the system partition to an image file. To back up the system partition: 1 Press the Novo button to start the Lenovo OneKey Recovery system. 2 Click System Backup. 3 Select a back-up location and click Next to start the backup. Notes: • You can choose a back-up location on the local hard disk drive or an external storage device. • The back-up process may take a while. • The back-up process is only available when Windows can be started normally. · Restoring You can choose to restore the system partition to its original status or to a previously created back-up point. To restore the system partition: 1 Press the Novo button to start the Lenovo OneKey Recovery system. 2 Click System Recovery. The computer will restart to the recovery environment. 3 Follow the on-screen instructions to restore the system partition to its original status or to a previously created back-up point. Notes: • The recovery process is irreversible. Make sure to back up any data you wish to save on the system partition before starting the recovery process. • The recovery process may take a while. So be sure to connect the AC power adapter to your computer during the recovery process. • The above instructions should be followed when Windows can be started normally. If Windows cannot be started, follow the steps below to start the Lenovo OneKey Recovery system: 1 Shut down the computer. 2 Press the Novo button. From Novo Button Menu, select System recovery and press Enter. This laptop has three partitions coded 2700 which I presume are for supporting this, plus a partition coded ed01 which I presume is the code executed from the "Novo" button. I've only used this button to switch to BIOS for linux, from EFI/Windows. > FreeBSD is different in this respect. No part of third-party software > ever gets into the base system (unless you install something manually > and incorrectly). This has already been pointed out, that Debian's installed system is an individual outcome, not some sort of mandated selection. > And of course you don't lose any user data if you run > "pkg delete -a" I didn't know we were discussing user data at all. > > Debian doesn't work that way: you can remove packages from the system > > at will in a controlled manner. Isn't that what sysadmins do? > > Well, I was not feeling particulary sysadmin-ish about the desktop > system I wanted to cleanup. How you feel about it can't alter the fact that reverting a system by removing packages is a sysadmin-ish process: you administering the system. > > > > "apt has a bug, cannot believe it!" > > > >
Re: Return a Debian system to a pristine state
On Lu, 01 iun 20, 12:26:28, Marco Möller wrote: > On 01.06.20 08:04, Andrei POPESCU wrote: > > On Sb, 30 mai 20, 19:54:09, Marco Möller wrote: > > > > > > From the view of a user, it does not sound so complicated ;-) . I guess, > > > and > > > this will be fair, that I am now asked to program it, it's open source > > > and I > > > should contribute. But unfortunately I can only contribute ideas, I am > > > not a > > > programmer. :-( > > APT is possibly not be best place to implement something like this, > > especially since there are various other softwares that do more or less > > what you want: > > > > debootstrap, mmdebstrap, FAI: custom installations Forgot to mention vmdb2 (build images or installations from scratch)... > > ansible, puppet, etc.: shape your installation as needed. ... and equivs, to easily build your own meta-packages. > > Or integrate with your backup strategy (you do have backups, right?). > > I strongly suggest that the package manager cares for managing the packages. APT is already managing packages. It can also be improved in many ways related to it's core mission, like fixing bugs[1] and adding new features[1]. What you are requesting is for it to manage collections of possibly unrelated packages (no Depends/Recommends/Suggests/etc. relations). In my opinion this functionality is better and easier implemented in other tools. [1] which are close to 1000 :( [2] I'm looking forward to support for aptitude's search patterns. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
Tom Dial wrote: ... > In the fairly large number of posts in this thread I don't recall seeing > file system snapshots suggested. My current preference is ZFS, which I > know from experience to be up to what I understand to be the goal here. both timeshift and partclone have been mentioned. both can be used to do snapshots. while i have not fully tested either of them lately. i see now that there is clonezilla too. again i've not had cause to test any of these out, but i suspect they'd work. > However, root on ZFS is a distinctly non-standard and hands on install > that is fairly straightforward and decently documented, but not for > everyone. Moreover, ZFS is not DFSG and GPL compliant, and quite a few > users would avoid it because of that. > > Alternatives include LVM and btrfs, and possibly others. I have used LVM > snapshots a little, but not for this use case. It appears to have the > capability to accomplish the objective, as described in > > https://linuxconfig.org/create-and-restore-manual-logical-volume-snapshots > > for instance. > > I have not used btrfs and therefore have no opinion about its fitness > for the case at hand. songbird
Re: Return a Debian system to a pristine state
Marco Möller wrote: ... > The problem remains to simply remove a couple of packages without having > to go for a full blown system reinstall and all the necessary > requirements for organizing it well. As there is a package manager, it > is obviously a straight forward logic to expect it to do this job, > because this is exactly what a package manager is expected to manage. > All other suggestions which have been brought up in the thread are > workarounds for filling the gap where the package manager is not full > featured. > The short answer to this thread is that unfortunately Debian is not > prepared with a simple solution for this simple task, but sophisticated > workarounds are needed. Debian is fine as long as there is a partition image program that functions when needed. when it was important for me to have this sort of backup and restore of a pristine Debian system it worked well for me. i am now at a spot where i don't need that sort of functionality so i don't do that any more. songbird
Re: Return a Debian system to a pristine state
On 01.06.20 08:04, Andrei POPESCU wrote: On Sb, 30 mai 20, 19:54:09, Marco Möller wrote: From the view of a user, it does not sound so complicated ;-) . I guess, and this will be fair, that I am now asked to program it, it's open source and I should contribute. But unfortunately I can only contribute ideas, I am not a programmer. :-( APT is possibly not be best place to implement something like this, especially since there are various other softwares that do more or less what you want: debootstrap, mmdebstrap, FAI: custom installations ansible, puppet, etc.: shape your installation as needed. Or integrate with your backup strategy (you do have backups, right?). I strongly suggest that the package manager cares for managing the packages.
Re: Return a Debian system to a pristine state
On 01.06.20 04:41, emetib wrote: this has been an interesting topic, so what the hell, here's my two cents. for my vm's, i have a list off packages that i install as soon as the minimum/base install and reboot is done. 4 vm's, testing, stable, centos7, opensuse. i have no gui's on these only cli, just need to know how to configure things for other os's than debian and it becomes a simple cut and paste to get a system to be at what i need. have a home partition, not just a home dir, and back it up often with a timestamp on it, and do a --get-selections and dump it to a file that you back up also. also doing that is an easy way to compare what was installed and what is now installed. keep sensitive config files in a spot that you know is going to be backed up or on your home partition so they aren't overwritten with a new install. there was a suggestion about using a live distro to make a back up right away, never done it before, yet this is a great idea. i believe that someone (smarter than me) could write a simple script to put all user installed programs into a file and then reinstall them after a full-reinstall. i.e. bash_install_script.sh check if su add package to list continue with the install This is almost exactly what I am also doing. The problem remains to simply remove a couple of packages without having to go for a full blown system reinstall and all the necessary requirements for organizing it well. As there is a package manager, it is obviously a straight forward logic to expect it to do this job, because this is exactly what a package manager is expected to manage. All other suggestions which have been brought up in the thread are workarounds for filling the gap where the package manager is not full featured. The short answer to this thread is that unfortunately Debian is not prepared with a simple solution for this simple task, but sophisticated workarounds are needed.
Re: Return a Debian system to a pristine state
On 01.06.20 04:52, Tom Dial wrote: On 5/31/20 03:28, Victor Sudakov wrote: David Wright wrote: On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: David Wright wrote: Finally, pkg delete -a sounds like something from the abattoir, rather than anything you'd do to a pet (to use your analogy). It's not as terrible as it sounds ;-) It's more from a vet clinic than from a slaughterhouse. You don't lose configs, you don't lose network connectivity or remote access during this procedure. You can save a list of installed packages before deleting them, and reinstall only those you know you need. Unfortunately, the FreeBSD package system is not as mature as DEB or RPM, therefore until very recently the "pkg delete -a" procedure has been required to get rid of the dependencey hell. OK, that sounds more like what people do on Windows systems, where there's a reset option, except that on Windows you can, ISTR, lose all your own files if they're under C:. Since what version does Windows have a reset option? For dozens of years, literally, Windows has been notorious for leftovers of removed programs remaining in the "base system" and causing unexpected effects. There were even commercial products on the market to purge those leftovers. FreeBSD is different in this respect. No part of third-party software ever gets into the base system (unless you install something manually and incorrectly). And of course you don't lose any user data if you run "pkg delete -a" Debian doesn't work that way: you can remove packages from the system at will in a controlled manner. Isn't that what sysadmins do? Well, I was not feeling particulary sysadmin-ish about the desktop system I wanted to cleanup. "apt has a bug, cannot believe it!" https://lists.debian.org/debian-user/2020/05/msg00567.html Well, I must admit, I can sympathize with this person's frustration. He just got confused among those AutoRemove* advanced options. I think it's much more than that. The OP appeared to regard the --no-install-recommends option as a *property* that is applied to each package installed under that recommendation regime, and that that property would be preserved for all time. But as the "-install-" in --no-install-recommends shows, it's just an option for the install command itself. Dare I say that one needs knowledge beyond a regular user to understand these subtleties? I, too, was surprised by some Debian features like its tendency to start daemons with a vanilla configuration right after installation. Still can't say I like this decision. This has been discussed in the past. Using the term "vanilla" suggests that an ordinary upstream configuration is applied to the daemon, which is not true: the Debian developers apply what they consider are sensible secure defaults, designed to integrate with the distribution. This work is usually documented in changelog.Debian.gz or various READMEs. Is the /usr/sbin/policy-rc.d method still the official supported one of disabling this behavior when it is not desirable? In the fairly large number of posts in this thread I don't recall seeing file system snapshots suggested. My current preference is ZFS, which I know from experience to be up to what I understand to be the goal here. (...) I understand the OP to be in search for the uncomplicated removal of installed packages considering package installation dates. A fs snaphot tool is likely to return to a general system state which would include also the return of the user data and system configurations to a point of time in the past, instead of only treating package installs. And if having to prepare sophisticated steps like requiring special partitioning schemes, then this wouldn't be uncomplicated anymore.
Re: Return a Debian system to a pristine state
On Du, 31 mai 20, 20:52:06, Tom Dial wrote: > > Moreover, ZFS is not DFSG and GPL compliant, and quite a few > users would avoid it because of that. ZFS is licensed under the CDDL[1], which is both free (as in freedom) and DFGS *compliant*. It is also *incompatible* with the GPL, which means distributing a Linux kernel (GPL) including the ZFS modules is possibly illegal[2]. End users however are well within their rights (freedom 0 and 1)[3] to use this combination, as long as they don't share it with anyone else (freedoms 3 and 4)[3]. [1] https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License [2] As far as I know this was never tested in court [3] https://en.wikipedia.org/wiki/The_Free_Software_Definition Hope this explains, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On Sb, 30 mai 20, 19:54:09, Marco Möller wrote: > > From the view of a user, it does not sound so complicated ;-) . I guess, and > this will be fair, that I am now asked to program it, it's open source and I > should contribute. But unfortunately I can only contribute ideas, I am not a > programmer. :-( APT is possibly not be best place to implement something like this, especially since there are various other softwares that do more or less what you want: debootstrap, mmdebstrap, FAI: custom installations ansible, puppet, etc.: shape your installation as needed. Or integrate with your backup strategy (you do have backups, right?). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On 5/31/20 03:28, Victor Sudakov wrote: > David Wright wrote: >> On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: >>> David Wright wrote: Finally, pkg delete -a sounds like something from the abattoir, rather than anything you'd do to a pet (to use your analogy). >>> >>> It's not as terrible as it sounds ;-) It's more from a vet clinic than >>> from a slaughterhouse. You don't lose configs, you don't lose network >>> connectivity or remote access during this procedure. You can save a list >>> of installed packages before deleting them, and reinstall only those you >>> know you need. >>> >>> Unfortunately, the FreeBSD package system is not as mature as DEB or >>> RPM, therefore until very recently the "pkg delete -a" procedure has >>> been required to get rid of the dependencey hell. >> >> OK, that sounds more like what people do on Windows systems, where >> there's a reset option, except that on Windows you can, ISTR, lose >> all your own files if they're under C:. > > Since what version does Windows have a reset option? For dozens of > years, literally, Windows has been notorious for leftovers of removed > programs remaining in the "base system" and causing unexpected effects. > There were even commercial products on the market to purge those leftovers. > > FreeBSD is different in this respect. No part of third-party software > ever gets into the base system (unless you install something manually > and incorrectly). And of course you don't lose any user data if you run > "pkg delete -a" > >> >> Debian doesn't work that way: you can remove packages from the system >> at will in a controlled manner. Isn't that what sysadmins do? > > Well, I was not feeling particulary sysadmin-ish about the desktop > system I wanted to cleanup. > >> "apt has a bug, cannot believe it!" https://lists.debian.org/debian-user/2020/05/msg00567.html >>> >>> Well, I must admit, I can sympathize with this person's frustration. He >>> just got confused among those AutoRemove* advanced options. >> >> I think it's much more than that. The OP appeared to regard the >> --no-install-recommends option as a *property* that is applied to each >> package installed under that recommendation regime, and that >> that property would be preserved for all time. But as the "-install-" >> in --no-install-recommends shows, it's just an option for the install >> command itself. > > Dare I say that one needs knowledge beyond a regular user to understand > these subtleties? > >> >>> I, too, was surprised by some Debian features like its tendency to start >>> daemons with a vanilla configuration right after installation. Still >>> can't say I like this decision. >> >> This has been discussed in the past. Using the term "vanilla" suggests >> that an ordinary upstream configuration is applied to the daemon, >> which is not true: the Debian developers apply what they consider are >> sensible secure defaults, designed to integrate with the distribution. >> This work is usually documented in changelog.Debian.gz or various >> READMEs. > > Is the /usr/sbin/policy-rc.d method still the official supported one of > disabling this behavior when it is not desirable? > In the fairly large number of posts in this thread I don't recall seeing file system snapshots suggested. My current preference is ZFS, which I know from experience to be up to what I understand to be the goal here. However, root on ZFS is a distinctly non-standard and hands on install that is fairly straightforward and decently documented, but not for everyone. Moreover, ZFS is not DFSG and GPL compliant, and quite a few users would avoid it because of that. Alternatives include LVM and btrfs, and possibly others. I have used LVM snapshots a little, but not for this use case. It appears to have the capability to accomplish the objective, as described in https://linuxconfig.org/create-and-restore-manual-logical-volume-snapshots for instance. I have not used btrfs and therefore have no opinion about its fitness for the case at hand. Regards, Tom Dial
Re: Return a Debian system to a pristine state
this has been an interesting topic, so what the hell, here's my two cents. for my vm's, i have a list off packages that i install as soon as the minimum/base install and reboot is done. 4 vm's, testing, stable, centos7, opensuse. i have no gui's on these only cli, just need to know how to configure things for other os's than debian and it becomes a simple cut and paste to get a system to be at what i need. have a home partition, not just a home dir, and back it up often with a timestamp on it, and do a --get-selections and dump it to a file that you back up also. also doing that is an easy way to compare what was installed and what is now installed. keep sensitive config files in a spot that you know is going to be backed up or on your home partition so they aren't overwritten with a new install. there was a suggestion about using a live distro to make a back up right away, never done it before, yet this is a great idea. i believe that someone (smarter than me) could write a simple script to put all user installed programs into a file and then reinstall them after a full-reinstall. i.e. bash_install_script.sh check if su add package to list continue with the install take care em
Re: Return a Debian system to a pristine state
On 31/05/2020 20:52, rhkra...@gmail.com wrote: On Sunday, May 31, 2020 01:43:46 PM Michael Howard wrote: On 31/05/2020 15:59, Thomas Schmitt wrote: If a backup shall have a chance to be absolutely safe it must be done while the backuped filesystems are unmounted or mounted read-only. Obviously. Obvious to some, but bares repeating for those of us with less experience / knowledge. Indeed. One should never assume the extent of somebody else's knowledge. -- Michael Howard
Re: Return a Debian system to a pristine state
On Sunday, May 31, 2020 01:43:46 PM Michael Howard wrote: > On 31/05/2020 15:59, Thomas Schmitt wrote: > > If a backup shall have a chance to be absolutely safe it must be done > > while the backuped filesystems are unmounted or mounted read-only. > > Obviously. Obvious to some, but bares repeating for those of us with less experience / knowledge.
Re: Return a Debian system to a pristine state
Hi, i wrote: > > Do we have a feature to get a list of installed packages and to later > > use it for re-installation ? Dan Ritter wrote: > Yes. dpkg --get-selections and its reverse, dpkg --set-selections Ahum. 2876 packages reported as installed. An ever growing number with each release, i assume. My Sid VM for packaging has 2678. But 331 are marked "deinstall" in contrast to only one on the host. (Why did my Sid ever have yum ?) > RAID for hardware reliability. Version control and/or snapshots for > minor error correction. Backups for major issues. Households > don't usually need to go further than that. Hey. That's enough for a medium sized company. :)) I wrote: > > I normally need weeks to get everything installed on my next machine. Michael Howard wrote: > Well then it's not pristine, which is what the OP wanted. Indeed. My statement was more meant as excuse why i did not know about a thing like dpkg --get-selections and --set-selections. I simply never have a pristine state worth restoring. An installation is complete when it does what i need. But then it cannot be considered pristine any more. (Nevertheless i care to have some backup Blu-rays of the non-volatile system files besides my user data backups.) Have a nice day :) Thomas
Re: Return a Debian system to a pristine state
On 31/05/2020 15:59, Thomas Schmitt wrote: Hi, Michael Howard wrote: With linux (debian) you could just create an image (using dd for example) of the drive in order to restore it at a later date. If a backup shall have a chance to be absolutely safe it must be done while the backuped filesystems are unmounted or mounted read-only. Obviously. This implies that it must be done by an operating system that it not using these to-be-backuped filesystems for its own needs. Debian Live comes to my mind. As good a choice as any. Do we have a feature to get a list of installed packages and to later use it for re-installation ? I normally need weeks to get everything installed on my next machine. In the beginning it is easy to choose the big chunks. But the previous machine is then old as stone and can hardly serve for the fine tuning. So i need to find out what's still missing and install on demand. Well then it's not pristine, which is what the OP wanted. -- Michael Howard
Re: Return a Debian system to a pristine state
On 31/05/2020 13:33, rhkra...@gmail.com wrote: On Sunday, May 31, 2020 07:39:13 AM Joe wrote: The Windows reset option is reinstallation, and always has been. For the last few versions, the installation medium is a partition on the hard drive, and it can be invoked from within Windows or from a BIOS startup key. From the peanut gallery: there is (or was?) that other function, not sure of the name (maybe including a phrase (or concept) like "go back"), by which you could take a snapshot of your system and then revert to that condition later. I never used it (I was gone from Windows before it came along), I don't know the correct name (or if it changed over the years), whether it still exists, and whether it affected the system programs, the user's data files, or both (or maybe it was selective). As with any system 'backup' utility, you need space/storage. Just how much depends on how you go about achieving your aims. Then there is time. How much time to record the state you are in and how much time to revert to that state. With MS Windows, system restore can be enabled on any drive (default is the system drive) but it's not foolproof in restoring (though pretty good by MS standards) and it takes up valuable (on small ssd) space on the drive. With linux (debian) you could just create an image (using dd for example) of the drive in order to restore it at a later date. However, with debian, if you want to revert to a pristine state, what is easier or quicker than doing a re-install? Just retain (or obtain) a copy of the original install media. It doesnt get much quicker than a barebones netinst of debian. -- Michael Howard
Re: Return a Debian system to a pristine state
Thomas Schmitt wrote: > Do we have a feature to get a list of installed packages and to later > use it for re-installation ? Yes. dpkg --get-selections and its reverse, dpkg --set-selections to which one might want to add a backup of /etc and /var, at a minimum. And presumably /home. > I normally need weeks to get everything installed on my next machine. > In the beginning it is easy to choose the big chunks. But the previous > machine is then old as stone and can hardly serve for the fine tuning. > So i need to find out what's still missing and install on demand. When we need to deploy the same set of software and tweak the same configs across multiple machines, we use configuration management software. Chef, puppet, ansible, salt, bcfg2, cfengine, vagrant there are lots of these systems. But for one person and one or two machines, they're overkill. RAID for hardware reliability. Version control and/or snapshots for minor error correction. Backups for major issues. Households don't usually need to go further than that. -dsr-
Re: Return a Debian system to a pristine state
Hi, Michael Howard wrote: > With linux (debian) you could just create an image (using dd for example) of > the drive in order to restore it at a later date. If a backup shall have a chance to be absolutely safe it must be done while the backuped filesystems are unmounted or mounted read-only. This implies that it must be done by an operating system that it not using these to-be-backuped filesystems for its own needs. Debian Live comes to my mind. The risk of backing up a write enabled filesystem is in the time span of the backup procedure. Around this time, the consistency of files like data bases is endangered by copying one file or file part while it is in an older state and later a file or file part which is already in a newer state. With data bases there is usually a software specific procedure to get a consistent snapshot without shutting them down. But in general there are too many things which could go wrong in this aspect. Filesystem snapshots reduce the risk but cannot completely avoid it, because the filesystem is not aware of all semantic interconnections between file content. They help by making the time window for such mishaps smaller. But only one of a group of consistency-sensitive write operations has to lie on the other side of the snapshot time to create a chance for inconsistency. The problem is not that important if you make frequent backups for recovery of small and big disasters while taking special care of data bases. The resulting backups are still better than nothing and potential inconsistencies can in most cases be resolved by using files from the next older backup. > However, with debian, if you want to revert to a pristine state, what is > easier or quicker than doing a re-install? Do we have a feature to get a list of installed packages and to later use it for re-installation ? I normally need weeks to get everything installed on my next machine. In the beginning it is easy to choose the big chunks. But the previous machine is then old as stone and can hardly serve for the fine tuning. So i need to find out what's still missing and install on demand. Have a nice day :) Thomas
Re: Return a Debian system to a pristine state
On 2020-05-31 at 08:33, rhkra...@gmail.com wrote: > On Sunday, May 31, 2020 07:39:13 AM Joe wrote: > >> The Windows reset option is reinstallation, and always has been. >> For the last few versions, the installation medium is a partition >> on the hard drive, and it can be invoked from within Windows or >> from a BIOS startup key. > > From the peanut gallery: there is (or was?) that other function, not > sure of the name (maybe including a phrase (or concept) like "go > back"), by which you could take a snapshot of your system and then > revert to that condition later. > > I never used it (I was gone from Windows before it came along), I > don't know the correct name (or if it changed over the years), > whether it still exists, and whether it affected the system programs, > the user's data files, or both (or maybe it was selective). You're probably talking about "System Restore". Reverting to an earlier system state that way doesn't affect user data files, although I believe it can affect system configuration settings (e.g., file-type associations). I think it can affect installed programs in some cases, but not all. It definitely affects Windows updates, driver changes, et cetera. It's never been the most reliable feature, but there are definitely scenarios in which it's nice to have around as an option, although the question of whether it's worth the disk-space (etc.) cost is one on which as far as I can tell the jury is still out. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Return a Debian system to a pristine state
Hi, 31 mai 2020 à 14:33 de rhkra...@gmail.com: > From the peanut gallery: there is (or was?) that other function, not sure of > the name (maybe including a phrase (or concept) like "go back"), by which you > could take a snapshot of your system and then revert to that condition later. > > I never used it (I was gone from Windows before it came along), I don't know > the correct name (or if it changed over the years), whether it still exists, > and whether it affected the system programs, the user's data files, or both > (or > maybe it was selective). > It's called System Restore on Win 7, 8 & 10. It's under System Protection for Storage. Windows create restore points for you automatically (before some notable events like installations for example) but you can create manual ones. This restoration feature doesn't affect data, only programs and drivers. Best regards, l0f4r0
Re: Return a Debian system to a pristine state
On Sunday, May 31, 2020 07:39:13 AM Joe wrote: > The Windows reset option is reinstallation, and always has been. For > the last few versions, the installation medium is a partition on the > hard drive, and it can be invoked from within Windows or from a BIOS > startup key. From the peanut gallery: there is (or was?) that other function, not sure of the name (maybe including a phrase (or concept) like "go back"), by which you could take a snapshot of your system and then revert to that condition later. I never used it (I was gone from Windows before it came along), I don't know the correct name (or if it changed over the years), whether it still exists, and whether it affected the system programs, the user's data files, or both (or maybe it was selective).
Re: Return a Debian system to a pristine state
On Sun, 31 May 2020 16:28:34 +0700 Victor Sudakov wrote: > > Since what version does Windows have a reset option? For dozens of > years, literally, Windows has been notorious for leftovers of removed > programs remaining in the "base system" and causing unexpected > effects. There were even commercial products on the market to purge > those leftovers. The Windows reset option is reinstallation, and always has been. For the last few versions, the installation medium is a partition on the hard drive, and it can be invoked from within Windows or from a BIOS startup key. Reinstallation restores the partitioning to the factory configuration, and formats the partitions, and the factory partitioning scheme fills the entire drive. Nothing survives, so data which must be kept must be lifted off the hard drive entirely. Additional hard drives fitted after sale to the machine are not touched, as far as I know. Uninstallation of individual programs is certainly not reliable. -- Joe
Re: Return a Debian system to a pristine state
David Wright wrote: > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: > > David Wright wrote: > > > Finally, pkg delete -a sounds like something from the abattoir, > > > rather than anything you'd do to a pet (to use your analogy). > > > > It's not as terrible as it sounds ;-) It's more from a vet clinic than > > from a slaughterhouse. You don't lose configs, you don't lose network > > connectivity or remote access during this procedure. You can save a list > > of installed packages before deleting them, and reinstall only those you > > know you need. > > > > Unfortunately, the FreeBSD package system is not as mature as DEB or > > RPM, therefore until very recently the "pkg delete -a" procedure has > > been required to get rid of the dependencey hell. > > OK, that sounds more like what people do on Windows systems, where > there's a reset option, except that on Windows you can, ISTR, lose > all your own files if they're under C:. Since what version does Windows have a reset option? For dozens of years, literally, Windows has been notorious for leftovers of removed programs remaining in the "base system" and causing unexpected effects. There were even commercial products on the market to purge those leftovers. FreeBSD is different in this respect. No part of third-party software ever gets into the base system (unless you install something manually and incorrectly). And of course you don't lose any user data if you run "pkg delete -a" > > Debian doesn't work that way: you can remove packages from the system > at will in a controlled manner. Isn't that what sysadmins do? Well, I was not feeling particulary sysadmin-ish about the desktop system I wanted to cleanup. > > > > "apt has a bug, cannot believe it!" > > > https://lists.debian.org/debian-user/2020/05/msg00567.html > > > > Well, I must admit, I can sympathize with this person's frustration. He > > just got confused among those AutoRemove* advanced options. > > I think it's much more than that. The OP appeared to regard the > --no-install-recommends option as a *property* that is applied to each > package installed under that recommendation regime, and that > that property would be preserved for all time. But as the "-install-" > in --no-install-recommends shows, it's just an option for the install > command itself. Dare I say that one needs knowledge beyond a regular user to understand these subtleties? > > > I, too, was surprised by some Debian features like its tendency to start > > daemons with a vanilla configuration right after installation. Still > > can't say I like this decision. > > This has been discussed in the past. Using the term "vanilla" suggests > that an ordinary upstream configuration is applied to the daemon, > which is not true: the Debian developers apply what they consider are > sensible secure defaults, designed to integrate with the distribution. > This work is usually documented in changelog.Debian.gz or various > READMEs. Is the /usr/sbin/policy-rc.d method still the official supported one of disabling this behavior when it is not desirable? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On 30.05.20 05:00, David Wright wrote: On Fri 29 May 2020 at 22:23:23 (+0200), Marco Möller wrote: On 29.05.20 21:48, David Wright wrote: On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: (...) "apt has a bug, cannot believe it!" https://lists.debian.org/debian-user/2020/05/msg00567.html Well, I must admit, I can sympathize with this person's frustration. He just got confused among those AutoRemove* advanced options. I think it's much more than that. The OP appeared to regard the --no-install-recommends option as a *property* that is applied to each package installed under that recommendation regime, and that that property would be preserved for all time. But as the "-install-" in --no-install-recommends shows, it's just an option for the install command itself. (...) Here the OP of that thread. Exactly this, David. I would really wish that the "--no-install-recommends" option would act as a "--no-recommends-wished" option! (...) Yes, a bigger work load on apt itself, but I really think it would be worth it. Just consider how many of us are forced to set up sophisticated backup strategies, or applying for this file system snapshot tools to act as a "time machine", while an enhanced apt could target this need in an easy an elegant fashion for the user (not speaking about the user's data and about the configuration of the packages, but speaking about the installation state of software packages)! You seem to be suggesting a one-dimensional install/undo facility, but an installation is a multi-dimensional graph of packages and dependencies. It's rare that one would want to just backtrack through a de-installation in the exact reverse order of installation. I also think it would be difficult to support, as it would give people unrealistic expectations of what's possible. In the sense of my wish, any removal or purge of a package would do the following (illustrating the idea and being aware that for sure some more in depth thoughts will have to be spent on it): (0) allow the user to store in some config file a list of time stamps which then could be respected as an option in the below outlined algorithm; the config file could look like this and for instance a leading integer number could later on be used for addressing a certain time stamp: 1; timestamp; essential OS after the initial installation 2; timestamp; added all my packages for a personalized CLI experience 3; timestamp; my minimum graphical DE is installed 4; timestamp; my full workstation, pristine, nice fall back state 5; timestamp; enhancements, quite good achievements 6; timestamp; testing 7; timestamp; arbitrary user comment default=4 The first entry "1" could be stored automatically by the Debian installer after the OS install and first reboot finished successfully; the default could initially be set to 1; the user could edit this file (and then of course also change the default value to another integer value like 4 in the above example; invalid default values are always treated as if the youngest timestamp would have been defined, value 7 in my above example); An enhanced apt-cache database would have to register for each installed package the installation date and if (not which) recommends and if (not which) suggests have been wished to install; for the drawn in recommends and suggest a list of the packages which explicitly wished their installation has to be maintained in the database by storing this information in the entry of each installed package; With this information there would not arise a limitation for at any time defining time stamps in the config files, because the "wished" tree besides the "dependency" tree could be reconstructed for any time; (1a) if 'apt remove' or 'apt purge' are called with a timestamp option and not specifying a specific package name, for instance 'apt remove --keeptimestamp 3' then remove or purge all packages installed AFTER the time stamp (for example, regarding my config file in (0), by the option value '3' in '--keeptimestap 3', the minimum graphical DE installation would remain but everything installed afterwards would be removed; the below mentioned steps (1b), (2) and (3) are not to be executed no more; (1b) if a specific package name is mentioned, then read for this specific by 'apt remove' or 'apt purge' targeted package IF recommends and suggests have been wished by this package; IF NOT, then simply remove or purge the specific package, considering also the dependencies as usual, and continue at step (4); IF recommends or suggests have been wished then continue at step (2); (2) if NO time stamp option was given then use the default timestamp; check if any of the recommended and suggested packages have themselves registered in their database entry in the "wished by" list that they would be wished by any other installed package, considering all packages which have been installed before the time stamp to be
Re: Return a Debian system to a pristine state
On Sat, 2020-05-30 at 15:38 +0300, Andrei POPESCU wrote: > On Sb, 30 mai 20, 10:27:14, Tixy wrote: > > On Sat, 2020-05-30 at 08:06 +0300, Andrei POPESCU wrote: > > > On Sb, 30 mai 20, 10:51:37, Victor Sudakov wrote: > > > > John Hasler wrote: > > > > > Perhaps what you want is something which will tell you which > > > > > programs > > > > > have gone unused for the longest time. > > > > > > > > That would be nice too. > > > > > > As already mentioned, the package popularity-contest does that, > > > somewhat. > > > > But, if I remember correct, relies on filesystems having file > > access > > time-stamping enabled. Which for many years hasn't been the default > > or > > recommended, due to the extra disk accesses required (causing worse > > performance and SSD wear). > > According to mount(8) the default is 'relatime', which in my > understanding is a compromise, i.e. it should be good enough for > popularity-contest. Thanks, that prompted me to look at what relatime actually does (which I know was the modern default). In my previous readings I'd missed the fact that atime is updated every 24 hours. So yes, perfectly good for popularity-contest. -- Tixy
Re: Return a Debian system to a pristine state
On Sb, 30 mai 20, 10:27:14, Tixy wrote: > On Sat, 2020-05-30 at 08:06 +0300, Andrei POPESCU wrote: > > On Sb, 30 mai 20, 10:51:37, Victor Sudakov wrote: > > > John Hasler wrote: > > > > Perhaps what you want is something which will tell you which > > > > programs > > > > have gone unused for the longest time. > > > > > > That would be nice too. > > > > As already mentioned, the package popularity-contest does that, > > somewhat. > > But, if I remember correct, relies on filesystems having file access > time-stamping enabled. Which for many years hasn't been the default or > recommended, due to the extra disk accesses required (causing worse > performance and SSD wear). According to mount(8) the default is 'relatime', which in my understanding is a compromise, i.e. it should be good enough for popularity-contest. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
On Sat, 2020-05-30 at 08:06 +0300, Andrei POPESCU wrote: > On Sb, 30 mai 20, 10:51:37, Victor Sudakov wrote: > > John Hasler wrote: > > > Perhaps what you want is something which will tell you which > > > programs > > > have gone unused for the longest time. > > > > That would be nice too. > > As already mentioned, the package popularity-contest does that, > somewhat. But, if I remember correct, relies on filesystems having file access time-stamping enabled. Which for many years hasn't been the default or recommended, due to the extra disk accesses required (causing worse performance and SSD wear). -- Tixy
Re: Return a Debian system to a pristine state
On Sb, 30 mai 20, 10:51:37, Victor Sudakov wrote: > John Hasler wrote: > > > > Perhaps what you want is something which will tell you which programs > > have gone unused for the longest time. > > That would be nice too. As already mentioned, the package popularity-contest does that, somewhat. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
John Hasler wrote: > Victor writes: > > We are all familiar with the situation when after a long period of > > usage, a system becomes full of software which we once installed for > > some purpose and then abandoned or disused. > > No, we aren't. I've been running Debian since 1.1 was released and have > never experienced that problem. Maybe you document every package you install? > > > A gentle hint on what is an would be very much > > appreciated at such moments. > > How could a package management system possibly know that? That's where we come to my original question. A package management system cannot possibly know that, but it can save a list of packages present at the time of installation, for later comparison/rollback. Or I could have saved this list manually if I had known, or derive it from installation/apt logs. I however was erroneously assuming that this information was already saved somewhere and available for use, hence my original question. I did not expect a harsh reaction actually, as if I was saying a heresy. > > Perhaps what you want is something which will tell you which programs > have gone unused for the longest time. That would be nice too. But it would probably require the definition of a "program" which maybe some entity more abstract than a package. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On Fri 29 May 2020 at 22:23:23 (+0200), Marco Möller wrote: > On 29.05.20 21:48, David Wright wrote: > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: > (...) > > > > "apt has a bug, cannot believe it!" > > > > https://lists.debian.org/debian-user/2020/05/msg00567.html > > > > > > Well, I must admit, I can sympathize with this person's frustration. He > > > just got confused among those AutoRemove* advanced options. > > > > I think it's much more than that. The OP appeared to regard the > > --no-install-recommends option as a *property* that is applied to each > > package installed under that recommendation regime, and that > > that property would be preserved for all time. But as the "-install-" > > in --no-install-recommends shows, it's just an option for the install > > command itself. > (...) > > Here the OP of that thread. Exactly this, David. > I would really wish that the "--no-install-recommends" option would > act as a "--no-recommends-wished" option! Then, together with parsing > the apt log file(s) as suggested in that thread, an "undo" > functionality would become available. And concerning the OP of this > thread (and I imagine meeting many other user's needs, as well) such > "undo" applied to several packages could straight forward lead to the > return to a pristine state (independent of how somebody would like to > define this state) as asked for it here in this thread! Personally, I think you'd do better to avoid entirely the installation of Recommends automatically, and take responsibility for deciding just what you want installed. The Recommends and Suggests will be listed when you install packages, and you can always reread their names from the Packages files should you need reminding. > I should not complain, not being a programmer and not being able to > directly support Debian by myself, but... if you allow me to kindly > complain... apt should really advance in this sense. Hopefully apt > programmers are listening to us users and could make something > possible. To me as an outsider it appears to be needed that apt-cache > (?) would collect more information, collect for each package also with > which option and at which date it was installed and why it was > installed or drawn in, like by now it is only in the log files if you > cared to strictly only use "apt" instead of "apt-cache" and "apt-get" > directly. I always use apt-get because the CLI interface is more stable. The log records a timestamp, the command line, the packages' versions (and whether they were automatic), and another timestamp. I suspect that's exactly what you're seeing. > Yes, a bigger work load on apt itself, but I really think it > would be worth it. Just consider how many of us are forced to set up > sophisticated backup strategies, or applying for this file system > snapshot tools to act as a "time machine", while an enhanced apt could > target this need in an easy an elegant fashion for the user (not > speaking about the user's data and about the configuration of the > packages, but speaking about the installation state of software > packages)! You seem to be suggesting a one-dimensional install/undo facility, but an installation is a multi-dimensional graph of packages and dependencies. It's rare that one would want to just backtrack through a de-installation in the exact reverse order of installation. I also think it would be difficult to support, as it would give people unrealistic expectations of what's possible. Cheers, David.
Re: Return a Debian system to a pristine state
On 29.05.20 21:48, David Wright wrote: On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: (...) "apt has a bug, cannot believe it!" https://lists.debian.org/debian-user/2020/05/msg00567.html Well, I must admit, I can sympathize with this person's frustration. He just got confused among those AutoRemove* advanced options. I think it's much more than that. The OP appeared to regard the --no-install-recommends option as a *property* that is applied to each package installed under that recommendation regime, and that that property would be preserved for all time. But as the "-install-" in --no-install-recommends shows, it's just an option for the install command itself. (...) Here the OP of that thread. Exactly this, David. I would really wish that the "--no-install-recommends" option would act as a "--no-recommends-wished" option! Then, together with parsing the apt log file(s) as suggested in that thread, an "undo" functionality would become available. And concerning the OP of this thread (and I imagine meeting many other user's needs, as well) such "undo" applied to several packages could straight forward lead to the return to a pristine state (independent of how somebody would like to define this state) as asked for it here in this thread! I should not complain, not being a programmer and not being able to directly support Debian by myself, but... if you allow me to kindly complain... apt should really advance in this sense. Hopefully apt programmers are listening to us users and could make something possible. To me as an outsider it appears to be needed that apt-cache (?) would collect more information, collect for each package also with which option and at which date it was installed and why it was installed or drawn in, like by now it is only in the log files if you cared to strictly only use "apt" instead of "apt-cache" and "apt-get" directly. Yes, a bigger work load on apt itself, but I really think it would be worth it. Just consider how many of us are forced to set up sophisticated backup strategies, or applying for this file system snapshot tools to act as a "time machine", while an enhanced apt could target this need in an easy an elegant fashion for the user (not speaking about the user's data and about the configuration of the packages, but speaking about the installation state of software packages)! Best greetings, Marco.
Re: Return a Debian system to a pristine state
On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote: > David Wright wrote: > > Finally, pkg delete -a sounds like something from the abattoir, > > rather than anything you'd do to a pet (to use your analogy). > > It's not as terrible as it sounds ;-) It's more from a vet clinic than > from a slaughterhouse. You don't lose configs, you don't lose network > connectivity or remote access during this procedure. You can save a list > of installed packages before deleting them, and reinstall only those you > know you need. > > Unfortunately, the FreeBSD package system is not as mature as DEB or > RPM, therefore until very recently the "pkg delete -a" procedure has > been required to get rid of the dependencey hell. OK, that sounds more like what people do on Windows systems, where there's a reset option, except that on Windows you can, ISTR, lose all your own files if they're under C:. Debian doesn't work that way: you can remove packages from the system at will in a controlled manner. Isn't that what sysadmins do? > > "apt has a bug, cannot believe it!" > > https://lists.debian.org/debian-user/2020/05/msg00567.html > > Well, I must admit, I can sympathize with this person's frustration. He > just got confused among those AutoRemove* advanced options. I think it's much more than that. The OP appeared to regard the --no-install-recommends option as a *property* that is applied to each package installed under that recommendation regime, and that that property would be preserved for all time. But as the "-install-" in --no-install-recommends shows, it's just an option for the install command itself. > I, too, was surprised by some Debian features like its tendency to start > daemons with a vanilla configuration right after installation. Still > can't say I like this decision. This has been discussed in the past. Using the term "vanilla" suggests that an ordinary upstream configuration is applied to the daemon, which is not true: the Debian developers apply what they consider are sensible secure defaults, designed to integrate with the distribution. This work is usually documented in changelog.Debian.gz or various READMEs. Cheers, David.
Re: Return a Debian system to a pristine state
Victor writes: > We are all familiar with the situation when after a long period of > usage, a system becomes full of software which we once installed for > some purpose and then abandoned or disused. No, we aren't. I've been running Debian since 1.1 was released and have never experienced that problem. > A gentle hint on what is an would be very much > appreciated at such moments. How could a package management system possibly know that? Perhaps what you want is something which will tell you which programs have gone unused for the longest time. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Return a Debian system to a pristine state
Greg Wooledge wrote: > On Thu, May 28, 2020 at 09:34:51PM +0700, Victor Sudakov wrote: > > > > > dpkg --get-selections > /root/initial-packages > > > > > > > > > > Just hold on to that file, and it will allow you to return to this > > > > > state on the same machine, or conceivably even a different machine. > > > > > > > > Out of itself, this file will not allow me anything. But Charles Curley > > > > has named the debfoster utility which seems to do the closest thing to > > > > what I wanted to achieve. > > > > > > What?! > > > > > > It does PRECISELY WHAT YOU STATED you wanted to do! > > > > Well, I wanted a degree of automation, not just a > > "dpkg --get-selections | diff /root/initial-packages -" for visual > > analysis and manual removal. > > The reverse of dpkg --get-selections is dpkg --set-selections, which > you run using the saved file as input instead of output. Then you > follow this with something like "apt-get dselect-upgrade" to install > the packages necessary to make the new system match the old system. Sounds tricky (I've never used dselect and other low-level things before and don't know much of them) but I'll certainly save this paragraph for future reference. Thank you. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
Miles Fidelman wrote: > > > John Hasler wrote: > > > Victor writes: > > > > But *many* people do install productivity tools, office tools, games, > > > > developer environments separately after the install, and then regret > > > > it and wish to get rid of them cleanly. > > > What does > > > > > > apt remove --purge ; apt autoremove > > > > > > not do that you want done? > > Unfortunately it does not know what packages are unwanted, nor > > do I (the user) to tell it. > > > > We are all familiar with the situation when after a long period of > > usage, a system becomes full of software which we once installed for > > some purpose and then abandoned or disused. A gentle hint on what is an > > would be very much appreciated at such moments. > > > > Maybe the high-level package management software (aptitude?) is better > > at that? > > > Of course, in any serious server environment, one is likely to have lots of > software that was NOT installed through dpkg or apt - ranging from stuff > installed directly from tarballs, to local configurations & scripts. For such systems, one usually has backups/snapshots/archives of some kind, and sometimes even documentation. > > As far as I can tell, the only way to get to a "pristine" system, is to > rebuild from scratch. Yes, probably, for the server cattle it's the right approach. I have a number of ansible playbooks and don't hesitate to terminate an EC2 instance or a bhyve virtual machine. But sometimes it's such a pity to kill a desktop system. I've just been thinking of Android which is Linux based but has a very clear distinction between the base system and user packages. You can easily remove all the package bloat from an Android device (unless a package is preinstalled and is thus a part of the "base system). OTOH, a real return to the "pristine state" (a factory reset) is in fact equivalent to reinstalling from scratch because you lose all data and personalizations. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
David Wright wrote: [dd] > > Finally, pkg delete -a sounds like something from the abattoir, > rather than anything you'd do to a pet (to use your analogy). It's not as terrible as it sounds ;-) It's more from a vet clinic than from a slaughterhouse. You don't lose configs, you don't lose network connectivity or remote access during this procedure. You can save a list of installed packages before deleting them, and reinstall only those you know you need. Unfortunately, the FreeBSD package system is not as mature as DEB or RPM, therefore until very recently the "pkg delete -a" procedure has been required to get rid of the dependencey hell. > "apt has a bug, cannot believe it!" > https://lists.debian.org/debian-user/2020/05/msg00567.html Well, I must admit, I can sympathize with this person's frustration. He just got confused among those AutoRemove* advanced options. I, too, was surprised by some Debian features like its tendency to start daemons with a vanilla configuration right after installation. Still can't say I like this decision. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On 5/29/20 10:32 AM, Victor Sudakov wrote: John Hasler wrote: Victor writes: But *many* people do install productivity tools, office tools, games, developer environments separately after the install, and then regret it and wish to get rid of them cleanly. What does apt remove --purge ; apt autoremove not do that you want done? Unfortunately it does not know what packages are unwanted, nor do I (the user) to tell it. We are all familiar with the situation when after a long period of usage, a system becomes full of software which we once installed for some purpose and then abandoned or disused. A gentle hint on what is an would be very much appreciated at such moments. Maybe the high-level package management software (aptitude?) is better at that? Of course, in any serious server environment, one is likely to have lots of software that was NOT installed through dpkg or apt - ranging from stuff installed directly from tarballs, to local configurations & scripts. As far as I can tell, the only way to get to a "pristine" system, is to rebuild from scratch. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown
Re: Return a Debian system to a pristine state
John Hasler wrote: > Victor writes: > > But *many* people do install productivity tools, office tools, games, > > developer environments separately after the install, and then regret > > it and wish to get rid of them cleanly. > > What does > > apt remove --purge ; apt autoremove > > not do that you want done? Unfortunately it does not know what packages are unwanted, nor do I (the user) to tell it. We are all familiar with the situation when after a long period of usage, a system becomes full of software which we once installed for some purpose and then abandoned or disused. A gentle hint on what is an would be very much appreciated at such moments. Maybe the high-level package management software (aptitude?) is better at that? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On Jo, 28 mai 20, 10:56:14, John Hasler wrote: > Victor writes: > > But *many* people do install productivity tools, office tools, games, > > developer environments separately after the install, and then regret > > it and wish to get rid of them cleanly. > > What does > > apt remove --purge ; apt autoremove Let me turn that around a bit ;) apt purge ; apt autoremove --purge Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
Victor writes: > But *many* people do install productivity tools, office tools, games, > developer environments separately after the install, and then regret > it and wish to get rid of them cleanly. What does apt remove --purge ; apt autoremove not do that you want done? -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Return a Debian system to a pristine state
On 5/28/20 10:34 AM, Victor Sudakov wrote: Greg Wooledge wrote: On Thu, May 28, 2020 at 08:50:44PM +0700, Victor Sudakov wrote: What is searched for in Debian is the ability to remove the bloatware which was not present at the time of installation. But... but... it's precisely DURING the installation that most of the crappy "bloatware" GETS ONTO THE SYSTEM! What?! How meny people do you think install GNOME or KDE or XFCE separately after the install, as opposed to ACCEPTING A DEFAULT during the install? The way you put it, those GNOME or KDE or XFCE would be part of the "pristine system" and I'm fine with it. But *many* people do install productivity tools, office tools, games, developer environments separately after the install, and then regret it and wish to get rid of them cleanly. And then there are those of us who run servers, don't want any of the desktop applications - but then we know enough not to install it in the first place. We tend to be more worried about all the interdependcies installed/required by systemd - but that's another battle entirely. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown
Re: Return a Debian system to a pristine state
On Thu 28 May 2020 at 20:50:44 (+0700), Victor Sudakov wrote: > Greg Wooledge wrote: > > On Thu, May 28, 2020 at 12:15:41PM +0700, Victor Sudakov wrote: > > > Dan Ritter wrote: > > > > There is no pristine state for Debian. > > > > > > There should be, even if this "pristine state" is but a list of packages > > > at the moment of the first boot. > > > > But that set is NOT the same for everyone. The installer selects > > some based on the hardware that it discovers during the installation, > > I never said this pristine state should be the same for everyone. It is > not required. Even FreeBSD's "base system" is not the same for everyone > because installing some parts thereof is optional (sources, lib32 etc). > And if you compile the base system from source, there are literally > dozens of options not to compile this or that. > > What is searched for in Debian is the ability to remove the bloatware > which was not present at the time of installation. > > > and you select some in the task selection menu. Also, there are several > > different installer images, including some that are meant to be used as > > live, and some that have non-free firmware packages. > > > > If *you*, the one person on the planet who wants this, would like to > > achieve your goal, what you can do is get a snapshot of *your* packages > > immediately after the installation, by running > > > > dpkg --get-selections > /root/initial-packages > > > > Just hold on to that file, and it will allow you to return to this > > state on the same machine, or conceivably even a different machine. > > Out of itself, this file will not allow me anything. But Charles Curley > has named the debfoster utility which seems to do the closest thing to > what I wanted to achieve. > > Thanks again to Charles and if there are no other propositions, I think > we can close this thread. > > > > > If on the other hand your real goal is not to achieve package reduction, > > but instead to *complain* about Debian, well, you've already achieved > > it. > > > > If your real goal is not just to complain about Debian, but rather, > > to make Debian *change* something arbitrary, just so that you feel > > powerful, well, good luck with that. > > Let these remarks remain on your conscience. Twice in two days, someone has sent a post that grates. Yours was the milder one. The one from Marco Möller¹ was harsher, but you had the misfortune to follow it closely. Dan answered your post quite reasonably with "There is no pristine state for Debian", and your response was "There should be". Well, perhaps you should have piped up 25 years ago, and altered the philosophy of Debian radically. You've now been told about debfoster; it comes with risks: uninstalling packages always carries some risks because it's done on far fewer occasions. See how you get on with it, and there's a bug tracking system at https://www.debian.org/Bugs/ Finally, pkg delete -a sounds like something from the abattoir, rather than anything you'd do to a pet (to use your analogy). ¹ "apt has a bug, cannot believe it!" https://lists.debian.org/debian-user/2020/05/msg00567.html Cheers, David.
Re: Return a Debian system to a pristine state
On 28/05/2020 10:50, Victor Sudakov wrote: > What is searched for in Debian is the ability to remove the bloatware > which was not present at the time of installation. Software you manually added later isn't bloatware. You may not like it and want it removed, but you have to specifically install it. bloatware would be things installed during the initial installation (especially a minimal installation) that are unnecessary or undesirable.[0] [0]What's unnecessary or undesirable varies a lot between people. -- Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. -- Alan Perlis Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Return a Debian system to a pristine state
Miles Fidelman wrote: > Of course, the real way to return ANY system to a pristine state is to do a > re-install from scratch. > > Which, one might add, is why we have things like Ansible. Yes, it's the well-known "pet vs cattle" dilemma. I still treat *some* of my machines as pets, and still cannot get used to treating all machines as cattle. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On Thu, May 28, 2020 at 09:34:51PM +0700, Victor Sudakov wrote: > > > > dpkg --get-selections > /root/initial-packages > > > > > > > > Just hold on to that file, and it will allow you to return to this > > > > state on the same machine, or conceivably even a different machine. > > > > > > Out of itself, this file will not allow me anything. But Charles Curley > > > has named the debfoster utility which seems to do the closest thing to > > > what I wanted to achieve. > > > > What?! > > > > It does PRECISELY WHAT YOU STATED you wanted to do! > > Well, I wanted a degree of automation, not just a > "dpkg --get-selections | diff /root/initial-packages -" for visual > analysis and manual removal. The reverse of dpkg --get-selections is dpkg --set-selections, which you run using the saved file as input instead of output. Then you follow this with something like "apt-get dselect-upgrade" to install the packages necessary to make the new system match the old system. Now, I've never used this to *remove* packages -- only to install new packages after a (re)install. I'm not sure how it handles removal of packages. Maybe there's an additional step required. Or maybe it just works as is. The fact that you just ASSUMED that it would require "manual removal" instead of thinking, "Hey, what is this --get-selections thing, maybe I should read some documentation about it, or ask more questions about it", is part of the problem here.
Re: Return a Debian system to a pristine state
Greg Wooledge wrote: > On Thu, May 28, 2020 at 08:50:44PM +0700, Victor Sudakov wrote: > > What is searched for in Debian is the ability to remove the bloatware > > which was not present at the time of installation. > > But... but... it's precisely DURING the installation that most of the > crappy "bloatware" GETS ONTO THE SYSTEM! What?! > > How meny people do you think install GNOME or KDE or XFCE separately > after the install, as opposed to ACCEPTING A DEFAULT during the install? The way you put it, those GNOME or KDE or XFCE would be part of the "pristine system" and I'm fine with it. But *many* people do install productivity tools, office tools, games, developer environments separately after the install, and then regret it and wish to get rid of them cleanly. > > > > dpkg --get-selections > /root/initial-packages > > > > > > Just hold on to that file, and it will allow you to return to this > > > state on the same machine, or conceivably even a different machine. > > > > Out of itself, this file will not allow me anything. But Charles Curley > > has named the debfoster utility which seems to do the closest thing to > > what I wanted to achieve. > > What?! > > It does PRECISELY WHAT YOU STATED you wanted to do! Well, I wanted a degree of automation, not just a "dpkg --get-selections | diff /root/initial-packages -" for visual analysis and manual removal. > > > Thanks again to Charles and if there are no other propositions, I think > > we can close this thread. > > Because you cannot be reasoned with? Sure, yes, OK, that is definitely > a reason for me to stop talking to you. > > I stand by everything I've said here. You have a secret agenda, and > your stated goal, which I told you how to accomplish, is not your > actual goal. I like conspiracy theories too. > That's why you rejected the solution you were given. I did not reject the solution I was given. I thanked Charles Curley for it, I think, at least twice. > > Call me bitchy or whatever you want, but I can SENSE this bullshit from > a mile away, and this is why I react the way I do. You react the way you do because you turned out not flexible enough to understand the problem and not knowledgeable enough to suggest a solution, which other people did. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
Of course, the real way to return ANY system to a pristine state is to do a re-install from scratch. Which, one might add, is why we have things like Ansible. Miles Fidelman On 5/28/20 1:15 AM, Victor Sudakov wrote: Dan Ritter wrote: Victor Sudakov wrote: A production system, especially a desktop system, tends to accumulate unnecessary packages. Users install software for testing, then forget about it, or it falls into disuse... In FreeBSD, you can always run "pkg delete -a" and return to the post-install state (well, almost). This command will remove all the third-party packages added to the base system after installation (modified files under /usr/local/ will remain). What's the procedure for Debian? There is no pristine state for Debian. There should be, even if this "pristine state" is but a list of packages at the moment of the first boot. Choices made during installation affect what the first boot experience looks like. The first boot experience is what can be called a pristine state. If something or someone saved that initial list of packages, it could be called "the pristine state." For the future, I'll always save the output of "dpkg -l" after the first boot for later comparison, but I did not expect it was not being done somewhere automatically already. [dd] /var/lib/apt/lists/* has package information; if you grep for Priority: required you will find packages that *must* be installed. The ranking is: required > important > standard > optional > extra This is interesting. This job of finding "extra" packages installed since the first boot can probably be done by the user, but I expected some ready solution to exist. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown
Re: Return a Debian system to a pristine state
On Thu, May 28, 2020 at 08:50:44PM +0700, Victor Sudakov wrote: [...] > What is searched for in Debian is the ability to remove the bloatware > which was not present at the time of installation. There is no bloatware in Debian [1] (Sorry, couldn't resist) Cheers [1] https://www.grunge.com/142773/the-truth-about-why-there-arent-snakes-in-ireland/ -- t signature.asc Description: Digital signature
Re: Return a Debian system to a pristine state
The Wanderer wrote: [dd] > > The suggestion of 'debfoster', from elsewhere in the thread, seems > reasonable as well. Although that would then mean that debfoster itself > would then be included in the list of base packages, which isn't > necessarily desirable and isn't technically accurate. Of course it's not necessary. Once I know that such a utility exists, I have no problem adding it to the list of packages I install first on any new system (among rsync, lsof, mtree-netbsd, netcat, screen, sockstat, csearch and many others). > > > If on the other hand your real goal is not to achieve package > > reduction, but instead to *complain* about Debian, well, you've > > already achieved it. > > > > If your real goal is not just to complain about Debian, but rather, > > to make Debian *change* something arbitrary, just so that you feel > > powerful, well, good luck with that. > > It seems to me that his goal (aside from finding a way to do the "revert > to pristine state" in his own case) is to persuade people that Debian > should implement, and in fact if possible should already have > implemented, Yes, I kind of expected that this problem had been solved and only my lack of knowledge prevents me from using a well-known solution. > a mechanism to make such a pristine-state reversion > possible in all cases - rather than having it be possible only if the > user took a particular action, which is not clearly documented or > suggested for that point, immediately after install. It is interesting that debfoster "maintains a list of installed packages that were explicitly requested rather than installed as a dependency." As a result, its list of unnecessary packages is rather short even long after the installation. Which is good of course. > > While I'm not particularly happy with the tone of his inquiries either, Sorry if I sounded harsh, this was not my intention (unless I was already facing an unjustifiedly hostile attitude from a couple of people). > and I doubt that I would ever use such a mechanism if it existed, the > basic idea doesn't seem like a particularly unreasonable one. I think > your own pushback against it probably goes too far in its own right. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On Thu, May 28, 2020 at 08:50:44PM +0700, Victor Sudakov wrote: > What is searched for in Debian is the ability to remove the bloatware > which was not present at the time of installation. But... but... it's precisely DURING the installation that most of the crappy "bloatware" GETS ONTO THE SYSTEM! How meny people do you think install GNOME or KDE or XFCE separately after the install, as opposed to ACCEPTING A DEFAULT during the install? > > dpkg --get-selections > /root/initial-packages > > > > Just hold on to that file, and it will allow you to return to this > > state on the same machine, or conceivably even a different machine. > > Out of itself, this file will not allow me anything. But Charles Curley > has named the debfoster utility which seems to do the closest thing to > what I wanted to achieve. What?! It does PRECISELY WHAT YOU STATED you wanted to do! > Thanks again to Charles and if there are no other propositions, I think > we can close this thread. Because you cannot be reasoned with? Sure, yes, OK, that is definitely a reason for me to stop talking to you. I stand by everything I've said here. You have a secret agenda, and your stated goal, which I told you how to accomplish, is not your actual goal. That's why you rejected the solution you were given. Call me bitchy or whatever you want, but I can SENSE this bullshit from a mile away, and this is why I react the way I do.
Re: Return a Debian system to a pristine state
Greg Wooledge wrote: > On Thu, May 28, 2020 at 12:15:41PM +0700, Victor Sudakov wrote: > > Dan Ritter wrote: > > > There is no pristine state for Debian. > > > > There should be, even if this "pristine state" is but a list of packages > > at the moment of the first boot. > > But that set is NOT the same for everyone. The installer selects > some based on the hardware that it discovers during the installation, I never said this pristine state should be the same for everyone. It is not required. Even FreeBSD's "base system" is not the same for everyone because installing some parts thereof is optional (sources, lib32 etc). And if you compile the base system from source, there are literally dozens of options not to compile this or that. What is searched for in Debian is the ability to remove the bloatware which was not present at the time of installation. > and you select some in the task selection menu. Also, there are several > different installer images, including some that are meant to be used as > live, and some that have non-free firmware packages. > > If *you*, the one person on the planet who wants this, would like to > achieve your goal, what you can do is get a snapshot of *your* packages > immediately after the installation, by running > > dpkg --get-selections > /root/initial-packages > > Just hold on to that file, and it will allow you to return to this > state on the same machine, or conceivably even a different machine. Out of itself, this file will not allow me anything. But Charles Curley has named the debfoster utility which seems to do the closest thing to what I wanted to achieve. Thanks again to Charles and if there are no other propositions, I think we can close this thread. > > If on the other hand your real goal is not to achieve package reduction, > but instead to *complain* about Debian, well, you've already achieved > it. > > If your real goal is not just to complain about Debian, but rather, > to make Debian *change* something arbitrary, just so that you feel > powerful, well, good luck with that. Let these remarks remain on your conscience. > -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On 2020-05-28 at 08:51, Greg Wooledge wrote: > There is simply no reasonable way to define what set of packages > would constitute a "pristine system" in Debian. The phrase has no > meaning. Yes, there is: "The set of packages which was present immediately after completion of the initial installation process." This will vary between computers, and indeed may vary between successive installs on the same computer, depending on the options chosen during the install process - but that doesn't make it any less reasonable of a definition for any given computer. At least two ways of identifying this set and making it possible to revert to that set have been suggested already in this thread, one of them by you. Why would the idea of asking for this to be handled automatically - so that the person doing a new install doesn't need to already be familiar with how to cause it to happen, despite not having necessarily had the experience needed to gain that familiarity - be such an unreasonable one that you push back against it in such harsh terms? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Return a Debian system to a pristine state
On Thu, May 28, 2020 at 08:00:09AM -0400, The Wanderer wrote: > Clearly that's not true, or there wouldn't be a user base for the way > FreeBSD does things which led him to have the expectation that this > would be possible. FreeBSD didn't separate packages from the base system just so a minuscule number of users could "revert to pristine state", because who the hell wants to do that? Almost nobody. The ability to remove all packages is simply a side effect of the design decision to have a small, centrally controlled, self-consistent base system. Everything else is a "package" -- an add-on that is not part of the base system, and may not have the same level of quality control and integration that the base system has. Debian doesn't work this way. The entire design is different. In Debian, every single thing is a "package",[1] but that doesn't necessarily mean "lower quality optional add-on thing that you can and should chuck into /dev/null at the first opportunity", which is what it means in BSD. Debian has no central "base system". It has only packages -- a package for the C library (libc6), a package for the init system (systemd), a package for the basic scripting shell (dash), and so on. Under BSD, all of these things would be part of the base system, and they would all be maintained by the same people. In Debian, each of them is maintained by a different person, or different group of people. They're not always in sync with each other, they way they are in BSD. There is simply no reasonable way to define what set of packages would constitute a "pristine system" in Debian. The phrase has no meaning. A handful of BSD users wishing that it had meaning doesn't make it so. [1] OK, to be fair, there is a magic tarball that lays out the file system during installation, before any packages can be installed. So, yes, there are a tiny handful of files that magically appear from the void during installation, that are not part of any package. But that's not a "base system" either.
Re: Return a Debian system to a pristine state
On Thu, May 28, 2020, 7:41 AM Greg Wooledge wrote: > On Thu, May 28, 2020 at 12:15:41PM +0700, Victor Sudakov wrote: > > Dan Ritter wrote: > > > There is no pristine state for Debian. > > > > There should be, even if this "pristine state" is but a list of packages > > at the moment of the first boot. > > But that set is NOT the same for everyone. The installer selects > some based on the hardware that it discovers during the installation, > and you select some in the task selection menu. Also, there are several > different installer images, including some that are meant to be used as > live, and some that have non-free firmware packages. > > If *you*, the one person on the planet who wants this, would like to > achieve your goal, what you can do is get a snapshot of *your* packages > immediately after the installation, by running > > dpkg --get-selections > /root/initial-packages > > Just hold on to that file, and it will allow you to return to this > state on the same machine, or conceivably even a different machine. > My approach to something similar (in my case, when Installation of the packages I want are complete, and the first "apt-get upgrade" is finished), is to do a clean Shutdown, boot from a Rescue CD (or USB), and issue a "tar cvf" on the Mounted Directory. Why "tar and feather" from another Linux, instead of the running one? To avoid the "Virtual File Systems", such as, for example, /proc. Good luck! Kenneth Parker
Re: Return a Debian system to a pristine state
Victor Sudakov wrote: > Dan Ritter wrote: > > Victor Sudakov wrote: > > > A production system, especially a desktop system, tends to accumulate > > > unnecessary packages. Users install software for testing, then forget > > > about it, or it falls into disuse... > > > > > > In FreeBSD, you can always run "pkg delete -a" and return to the > > > post-install state (well, almost). This command will remove all the > > > third-party packages added to the base system after installation > > > (modified files under /usr/local/ will remain). > > > > > > What's the procedure for Debian? > > > > There is no pristine state for Debian. > > There should be, even if this "pristine state" is but a list of packages > at the moment of the first boot. > The first boot experience is what can be called a pristine state. If > something or someone saved that initial list of packages, it could be > called "the pristine state." That won't be consistent against other installs of the same Debian version. The installer looks at the hardware it can find and asks you for selections that influence what it will install. If you answer the questions the same way every time on a particular machine, it will produce a consistent result. If you answer the questions differently, or the hardware is at all different, you will get a different result. Hardware manufacturers often substitute "equivalent" parts, so two identical machines from the same vendor might not actually be identical. For example, a laptop vendor might ship a mini-PCIe add-on card for bluetooth 4 and wifi b/g/n, but when they run out, might ship a slightly more expensive card that does bluetooth 5 and wifi b/g/n/ac -- with a different driver required. You might be interested in: - chef, puppet, ansible, salt: systems that enforce package installation and configuration across many machines - etckeeper: a version control system that operates semi-automatically on /etc - FAI, installer pre-seed, Debian Live: methods for producing as consistent an installation as possible across many machines -dsr-
Re: Return a Debian system to a pristine state
On 2020-05-28 at 07:40, Greg Wooledge wrote: > On Thu, May 28, 2020 at 12:15:41PM +0700, Victor Sudakov wrote: > >> Dan Ritter wrote: >> >>> There is no pristine state for Debian. >> >> There should be, even if this "pristine state" is but a list of >> packages at the moment of the first boot. > > But that set is NOT the same for everyone. The installer selects > some based on the hardware that it discovers during the > installation, and you select some in the task selection menu. Also, > there are several different installer images, including some that are > meant to be used as live, and some that have non-free firmware > packages. As you yourself note, that can be addressed by defining the "pristine state" package set at install time - either when and as the packages that are to be installed are selected, or immediately after the installation has completed - instead of trying to pre-define it before the install begins. > If *you*, the one person on the planet who wants this, Clearly that's not true, or there wouldn't be a user base for the way FreeBSD does things which led him to have the expectation that this would be possible. > would like to achieve your goal, what you can do is get a snapshot of > *your* packages immediately after the installation, by running > > dpkg --get-selections > /root/initial-packages > > Just hold on to that file, and it will allow you to return to this > state on the same machine, or conceivably even a different machine. The suggestion of 'debfoster', from elsewhere in the thread, seems reasonable as well. Although that would then mean that debfoster itself would then be included in the list of base packages, which isn't necessarily desirable and isn't technically accurate. > If on the other hand your real goal is not to achieve package > reduction, but instead to *complain* about Debian, well, you've > already achieved it. > > If your real goal is not just to complain about Debian, but rather, > to make Debian *change* something arbitrary, just so that you feel > powerful, well, good luck with that. It seems to me that his goal (aside from finding a way to do the "revert to pristine state" in his own case) is to persuade people that Debian should implement, and in fact if possible should already have implemented, a mechanism to make such a pristine-state reversion possible in all cases - rather than having it be possible only if the user took a particular action, which is not clearly documented or suggested for that point, immediately after install. While I'm not particularly happy with the tone of his inquiries either, and I doubt that I would ever use such a mechanism if it existed, the basic idea doesn't seem like a particularly unreasonable one. I think your own pushback against it probably goes too far in its own right. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Return a Debian system to a pristine state
On Thu, May 28, 2020 at 12:15:41PM +0700, Victor Sudakov wrote: > Dan Ritter wrote: > > There is no pristine state for Debian. > > There should be, even if this "pristine state" is but a list of packages > at the moment of the first boot. But that set is NOT the same for everyone. The installer selects some based on the hardware that it discovers during the installation, and you select some in the task selection menu. Also, there are several different installer images, including some that are meant to be used as live, and some that have non-free firmware packages. If *you*, the one person on the planet who wants this, would like to achieve your goal, what you can do is get a snapshot of *your* packages immediately after the installation, by running dpkg --get-selections > /root/initial-packages Just hold on to that file, and it will allow you to return to this state on the same machine, or conceivably even a different machine. If on the other hand your real goal is not to achieve package reduction, but instead to *complain* about Debian, well, you've already achieved it. If your real goal is not just to complain about Debian, but rather, to make Debian *change* something arbitrary, just so that you feel powerful, well, good luck with that.
Re: Return a Debian system to a pristine state
On Thu, May 28, 2020 at 11:09:42AM +0200, Sijmen J. Mulder wrote: > Victor Sudakov wrote: > > A production system, especially a desktop system, tends to accumulate > > unnecessary packages [...] > > What's the procedure for Debian? > > It helps to only look installed packages marked automatic [...] > ...which ties into the remark made a few times in this thread which is > that there is no singular set of base packages. That would be the packages marked "essential". But note that this will be much less than what a "normal desktop user" expects... Cheers -- tomás signature.asc Description: Digital signature
Re: Return a Debian system to a pristine state
Victor Sudakov wrote: > A production system, especially a desktop system, tends to accumulate > unnecessary packages. Users install software for testing, then forget > about it, or it falls into disuse... > > In FreeBSD, you can always run "pkg delete -a" and return to the > post-install state (well, almost). This command will remove all the > third-party packages added to the base system after installation > (modified files under /usr/local/ will remain). > > What's the procedure for Debian? It helps to only look installed packages marked automatic but lots of system programs and libraries are marked as such. I'd expect a 'base' metapackage of some sort... ...which ties into the remark made a few times in this thread which is that there is no singular set of base packages. But then at least have tasksel do something like that. Admittedly I just don't know a lot about Debian packages but as a user I have the same concern as Victor. Sijmen
Re: Return a Debian system to a pristine state
On Jo, 28 mai 20, 12:31:33, Victor Sudakov wrote: > Greg Wooledge wrote: > > > > In Debian, there is no such separation. There are only "packages", and > > these packages can be essential (what you'd consider part of the base > > system), or frivolous, or anywhere in between. The packaging system > > doesn't *know* which packages you would consider to be keep-worthy and > > which ones you would consider to be fluff. Only you would know that. > > I probably know that the packages present at the moment of the first > boot after installation are essential and keep-worthy. Can I do > something useful having this knowledge now? I don't agree. E.g. by default the Debian Installer will install Gnome. Does that mean Gnome is keep-worthy, even if I'm using LXDE? And even if I do select LXDE instead during the install, there are some components I might not need (e.g. I'm currently using xfce4-terminal instead of lxterminal). This is not even considering alternative methods of installation like debootstrap. For certain installations I find even the default debootstrap installation to be "bloated" and start with '--variant=minbase' instead (only 'Priority: required' and apt). Apparently 'mmdebstrap' can make even smaller installs. Then there's also the choice of with or without Recommends, which has been debated a lot on this list (please search the archives). > > So, if you want to put the work in to achieve this goal, you can come > > up with a set of packages that *you* consider important enough to keep, > > and then simply purge everything else. > > So there is no software product which would suggest to me packages for > purging? Maybe even interactively? > > "Package XXX was installed YYY days after the system installation, would > you like to purge it and its dependencies? (y/n)" If packages were installed due to Depends (or Recommends if enabled) apt will suggest removing those that are not needed anymore, while obeying AutoRemove::RecommendsImportant and AutoRemove::SuggestsImportant (both enabled by default). If you have popularity-contest installed (and enabled?) there is popcon-largest-unused. I seem to recall it uses atime, so it might not work if you mount your system partition(s) noatime. Other cleaning options: aptitude purge '?config-files' aptitude purge '?garbage' aptitude purge '?obsolete' See the aptitude manual for the meaning of these (and many other interesting) search patterns. https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html Advanced queries of the dpkg database (locally installed packages) can be done with dpkg-query. Hope this helps, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Return a Debian system to a pristine state
Charles Curley wrote: > > > A production system, especially a desktop system, tends to accumulate > > unnecessary packages. Users install software for testing, then forget > > about it, or it falls into disuse... > > You might look into the package debfoster. Thanks, Charles! This looks like a very close hit. If I run "debfoster -q" right after installation, it would probably do what I was asking for. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
Greg Wooledge wrote: > > Victor Sudakov wrote: > > > In FreeBSD, you can always run "pkg delete -a" and return to the > > > post-install state (well, almost). This command will remove all the > > > third-party packages added to the base system after installation > > > (modified files under /usr/local/ will remain). > > That's because (Free|Open)BSD has a completely different approach to > how they develop their operating system. Under their model, there > are two completely *separate* parts of the operating system: the base > system, and packages. Packages are add-ons that are maintained by a > separate group. They're not part of the base system. They're installed > in /usr/local, and they're tracked separately. I know. I've been using FreeBSD for 25 years, since 1.1.5.1 probably. > > In Debian, there is no such separation. There are only "packages", and > these packages can be essential (what you'd consider part of the base > system), or frivolous, or anywhere in between. The packaging system > doesn't *know* which packages you would consider to be keep-worthy and > which ones you would consider to be fluff. Only you would know that. I probably know that the packages present at the moment of the first boot after installation are essential and keep-worthy. Can I do something useful having this knowledge now? > > So, if you want to put the work in to achieve this goal, you can come > up with a set of packages that *you* consider important enough to keep, > and then simply purge everything else. So there is no software product which would suggest to me packages for purging? Maybe even interactively? "Package XXX was installed YYY days after the system installation, would you like to purge it and its dependencies? (y/n)" That would be kinda nice. > > When you break the system, you will get to reinstall from scratch, which > is what you should have been doing in the first place, if you really want > to "clean up" a legacy installation. No, a reinstall from scratch is some Microsoft Windows approach, I'd refrain from if I possibly can. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
songbird wrote: > > > > A production system, especially a desktop system, tends to accumulate > > unnecessary packages. Users install software for testing, then forget > > about it, or it falls into disuse... > > > > In FreeBSD, you can always run "pkg delete -a" and return to the > > post-install state (well, almost). This command will remove all the > > third-party packages added to the base system after installation > > (modified files under /usr/local/ will remain). > > > > What's the procedure for Debian? > > i don't think there is any one procedure as there are so > many different requirements that people can have and the > size of the installation may be quite different. As I wrote to Dan, a pristine state could be a list of packages at the moment of the first boot. Yes, it would be different for different installations, I don't see it as a major problem. > > when someone specifies a production system to me that means > they are likely running stable and not testing or unstable. Irrelevant for the question. > > you can find some information about what packages and > versions in /var/log/install and /var/log/apt if you've kept > those files. > > if as time has been long enough there may be updates from > the initial installed versions so i don't think you can always > count on downgrading to work for those. An automatic tool would be useful to analyze the above. I somehow expected something like that to exist. > > if you desire a specific image of a system to always be able > to boot and work then there would have to be some other way > to do that IMO. i have not yet used timeshift as my backup > and recovery needs are not that great (instead i keep other > bootable versions available including one on a USB stick). > > there are other partition copying utilties and schemes that > can be used, but i've not had to mess with them recently enough. > a long time ago i was using partclone which did what i needed > it to do. No, backups and images is already a different story. Am I expected to always manually document somewhere that I installed some bloated piece of software, just to be able to remove it (and its dependencies) later when I don't need it? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
Dan Ritter wrote: > Victor Sudakov wrote: > > A production system, especially a desktop system, tends to accumulate > > unnecessary packages. Users install software for testing, then forget > > about it, or it falls into disuse... > > > > In FreeBSD, you can always run "pkg delete -a" and return to the > > post-install state (well, almost). This command will remove all the > > third-party packages added to the base system after installation > > (modified files under /usr/local/ will remain). > > > > What's the procedure for Debian? > > There is no pristine state for Debian. There should be, even if this "pristine state" is but a list of packages at the moment of the first boot. > Choices made during > installation affect what the first boot experience looks like. The first boot experience is what can be called a pristine state. If something or someone saved that initial list of packages, it could be called "the pristine state." For the future, I'll always save the output of "dpkg -l" after the first boot for later comparison, but I did not expect it was not being done somewhere automatically already. [dd] > > /var/lib/apt/lists/* has package information; if you grep for > Priority: required you will find packages that *must* be > installed. The ranking is: > > required > important > standard > optional > extra This is interesting. This job of finding "extra" packages installed since the first boot can probably be done by the user, but I expected some ready solution to exist. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Return a Debian system to a pristine state
On Wed, 27 May 2020 15:47:00 +0700 Victor Sudakov wrote: > A production system, especially a desktop system, tends to accumulate > unnecessary packages. Users install software for testing, then forget > about it, or it falls into disuse... You might look into the package debfoster. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Return a Debian system to a pristine state
> Victor Sudakov wrote: > > In FreeBSD, you can always run "pkg delete -a" and return to the > > post-install state (well, almost). This command will remove all the > > third-party packages added to the base system after installation > > (modified files under /usr/local/ will remain). That's because (Free|Open)BSD has a completely different approach to how they develop their operating system. Under their model, there are two completely *separate* parts of the operating system: the base system, and packages. Packages are add-ons that are maintained by a separate group. They're not part of the base system. They're installed in /usr/local, and they're tracked separately. In Debian, there is no such separation. There are only "packages", and these packages can be essential (what you'd consider part of the base system), or frivolous, or anywhere in between. The packaging system doesn't *know* which packages you would consider to be keep-worthy and which ones you would consider to be fluff. Only you would know that. So, if you want to put the work in to achieve this goal, you can come up with a set of packages that *you* consider important enough to keep, and then simply purge everything else. When you break the system, you will get to reinstall from scratch, which is what you should have been doing in the first place, if you really want to "clean up" a legacy installation.
Re: Return a Debian system to a pristine state
Victor Sudakov wrote: > Dear Colleagues, > > A production system, especially a desktop system, tends to accumulate > unnecessary packages. Users install software for testing, then forget > about it, or it falls into disuse... > > In FreeBSD, you can always run "pkg delete -a" and return to the > post-install state (well, almost). This command will remove all the > third-party packages added to the base system after installation > (modified files under /usr/local/ will remain). > > What's the procedure for Debian? i don't think there is any one procedure as there are so many different requirements that people can have and the size of the installation may be quite different. when someone specifies a production system to me that means they are likely running stable and not testing or unstable. you can find some information about what packages and versions in /var/log/install and /var/log/apt if you've kept those files. if as time has been long enough there may be updates from the initial installed versions so i don't think you can always count on downgrading to work for those. if you desire a specific image of a system to always be able to boot and work then there would have to be some other way to do that IMO. i have not yet used timeshift as my backup and recovery needs are not that great (instead i keep other bootable versions available including one on a USB stick). there are other partition copying utilties and schemes that can be used, but i've not had to mess with them recently enough. a long time ago i was using partclone which did what i needed it to do. songbird
Re: Return a Debian system to a pristine state
Victor Sudakov wrote: > A production system, especially a desktop system, tends to accumulate > unnecessary packages. Users install software for testing, then forget > about it, or it falls into disuse... > > In FreeBSD, you can always run "pkg delete -a" and return to the > post-install state (well, almost). This command will remove all the > third-party packages added to the base system after installation > (modified files under /usr/local/ will remain). > > What's the procedure for Debian? There is no pristine state for Debian. Choices made during installation affect what the first boot experience looks like. apt remove will uninstall a package. apt purge will uninstall a package and try to remove any configuration it has left behind. dpkg -S will tell you what package a file belongs to. apt-cache rdepends will tell you what other packages depend on an installed package. /var/lib/apt/lists/* has package information; if you grep for Priority: required you will find packages that *must* be installed. The ranking is: required > important > standard > optional > extra -dsr-
Return a Debian system to a pristine state
Dear Colleagues, A production system, especially a desktop system, tends to accumulate unnecessary packages. Users install software for testing, then forget about it, or it falls into disuse... In FreeBSD, you can always run "pkg delete -a" and return to the post-install state (well, almost). This command will remove all the third-party packages added to the base system after installation (modified files under /usr/local/ will remain). What's the procedure for Debian? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
