[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> 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


for instance.

I have not used btrfs and therefore have no opinion about its fitness
for the case at hand.

Tom Dial

Reply to: