Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #222750 > unrolled thread

Return a Debian system to a pristine state

Back to article view | Back to linux.debian.user

Contents

  Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-27 10:50 +0200
    Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-05-27 15:50 +0200
      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:20 +0200
        Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 13:50 +0200
          Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-05-28 14:10 +0200
            Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 15:00 +0200
              Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-05-28 15:10 +0200
            Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:20 +0200
          Re: Return a Debian system to a pristine state Kenneth Parker <sea7kenp@gmail.com> - 2020-05-28 14:50 +0200
          Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:00 +0200
            Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 16:10 +0200
              Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:40 +0200
                Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 16:50 +0200
                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 17:20 +0200
                Re: Return a Debian system to a pristine state John Hasler <jhasler@newsguy.com> - 2020-05-28 18:00 +0200
                  Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-29 09:50 +0200
                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 16:40 +0200
                    Re: Return a Debian system to a pristine state Miles Fidelman <mfidelman@meetinghouse.net> - 2020-05-29 16:50 +0200
                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 17:20 +0200
                    Re: Return a Debian system to a pristine state John Hasler <jhasler@newsguy.com> - 2020-05-29 17:40 +0200
                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-30 06:00 +0200
                        Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-30 07:10 +0200
                          Re: Return a Debian system to a pristine state Tixy <tixy@yxit.co.uk> - 2020-05-30 11:30 +0200
                            Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-30 14:40 +0200
                              Re: Return a Debian system to a pristine state Tixy <tixy@yxit.co.uk> - 2020-05-30 19:40 +0200
                Re: Return a Debian system to a pristine state Miles Fidelman <mfidelman@meetinghouse.net> - 2020-05-28 18:00 +0200
            Re: Return a Debian system to a pristine state <tomas@tuxteam.de> - 2020-05-28 16:40 +0200
            Re: Return a Debian system to a pristine state Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2020-05-28 17:10 +0200
            Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-05-28 17:10 +0200
              Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 17:00 +0200
                Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-05-29 21:50 +0200
                  Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-05-29 22:30 +0200
                    Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-05-30 05:10 +0200
                      Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-05-30 20:00 +0200
                        Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-01 08:10 +0200
                          Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-01 12:30 +0200
                            Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-01 20:00 +0200
                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-31 11:30 +0200
                    Re: Return a Debian system to a pristine state Joe <joe@jretrading.com> - 2020-05-31 13:40 +0200
                      Re: Return a Debian system to a pristine state rhkramer@gmail.com - 2020-05-31 14:40 +0200
                        Re: Return a Debian system to a pristine state l0f4r0@tuta.io - 2020-05-31 15:00 +0200
                        Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-05-31 15:00 +0200
                        Re: Return a Debian system to a pristine state Michael Howard <mike@dewberryfields.co.uk> - 2020-05-31 15:10 +0200
                          Re: Return a Debian system to a pristine state "Thomas Schmitt" <scdbackup@gmx.net> - 2020-05-31 17:00 +0200
                            Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-05-31 17:40 +0200
                              Re: Return a Debian system to a pristine state "Thomas Schmitt" <scdbackup@gmx.net> - 2020-05-31 21:00 +0200
                            Re: Return a Debian system to a pristine state Michael Howard <mike@dewberryfields.co.uk> - 2020-05-31 19:50 +0200
                              Re: Return a Debian system to a pristine state rhkramer@gmail.com - 2020-05-31 22:00 +0200
                                Re: Return a Debian system to a pristine state Michael Howard <mike@dewberryfields.co.uk> - 2020-05-31 23:40 +0200
                              Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-04 16:40 +0200
                                Re: Return a Debian system to a pristine state John Hasler <jhasler@newsguy.com> - 2020-06-04 22:50 +0200
                                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-06-05 17:40 +0200
                                    Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-06-05 18:10 +0200
                                      Re: Return a Debian system to a pristine state Brian <ad44@cityscape.co.uk> - 2020-06-06 12:30 +0200
                                        Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-06-06 13:00 +0200
                                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-06-07 14:00 +0200
                                Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-06 11:30 +0200
                                  Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-08 21:40 +0200
                                    Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-09 08:10 +0200
                                      Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-07-02 03:10 +0200
                    Re: Return a Debian system to a pristine state Tom Dial <tddial@comcast.net> - 2020-06-01 05:10 +0200
                      Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-01 08:30 +0200
                        Re: Return a Debian system to a pristine state Tom Dial <tddial@comcast.net> - 2020-06-02 00:40 +0200
                      Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-01 11:50 +0200
                        Re: Return a Debian system to a pristine state "Sijmen J. Mulder" <ik@sjmulder.nl> - 2020-06-04 10:50 +0200
                          Re: Return a Debian system to a pristine state Tom Dial <tddial@comcast.net> - 2020-06-04 21:20 +0200
                      Re: Return a Debian system to a pristine state songbird <songbird@anthive.com> - 2020-06-01 13:30 +0200
                    Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-01 20:30 +0200
                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-06-02 06:10 +0200
                        Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-02 07:30 +0200
                        Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-06-02 14:40 +0200
                        Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-02 17:10 +0200
                      Re: Override default post-install starting of services [was Return  a Debian system to a pristine state] davidson <davidson@freevolt.org> - 2020-07-05 22:20 +0200
                        Re: Override default post-install starting of services [was Return a  Debian system to a pristine state] David Wright <deblis@lionunicorn.co.uk> - 2020-07-05 23:40 +0200
        Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-05-28 14:10 +0200
        Re: Return a Debian system to a pristine state Miles Fidelman <mfidelman@meetinghouse.net> - 2020-05-28 16:40 +0200
          Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:50 +0200
    Re: Return a Debian system to a pristine state songbird <songbird@anthive.com> - 2020-05-27 16:10 +0200
      Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-27 16:30 +0200
        Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:40 +0200
          Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-28 08:10 +0200
      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:30 +0200
    Re: Return a Debian system to a pristine state Charles Curley <charlescurley@charlescurley.com> - 2020-05-27 20:10 +0200
      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:40 +0200
    Re: Return a Debian system to a pristine state "Sijmen J. Mulder" <ik@sjmulder.nl> - 2020-05-28 11:20 +0200
      Re: Return a Debian system to a pristine state <tomas@tuxteam.de> - 2020-05-28 11:30 +0200
    Re: Return a Debian system to a pristine state emetib <chadbrabec@gmail.com> - 2020-06-01 05:10 +0200
      Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-01 12:20 +0200
        Re: Return a Debian system to a pristine state songbird <songbird@anthive.com> - 2020-06-01 13:30 +0200
        Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-04 16:40 +0200
          Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-06-04 21:50 +0200
            Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-05 13:10 +0200
              Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-06 11:40 +0200
                Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-08 21:40 +0200

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#222909

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 <unwanted package> 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/

[toc] | [prev] | [next] | [standalone]

#222911

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#222915

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

[toc] | [prev] | [next] | [standalone]

#222918

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#222927

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 

[toc] | [prev] | [next] | [standalone]

#222827

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

[toc] | [prev] | [next] | [standalone]

#222815

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#222819

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
eduardo@kalinowski.com.br

[toc] | [prev] | [next] | [standalone]

#222821

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.

[toc] | [prev] | [next] | [standalone]

#222879

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/

[toc] | [prev] | [next] | [standalone]

#222895

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.

[toc] | [prev] | [next] | [standalone]

#222901

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.

[toc] | [prev] | [next] | [standalone]

#222908

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.

[toc] | [prev] | [next] | [standalone]

#222928

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 wished packages, 
and if for a package from the recommends and suggests list it now 
results that it is not wished any more, then besides removing or purging 
only the specified package do additionally also remove or purge the no 
more wished recommended and suggested package(s);
(3) iteratively follow the logic of step (2) for the additionally found 
packages which meanwhile became marked for removal or purge and work 
also on their list of recommends and suggests;

(4) in interactive mode show the list of for removal or purge marked 
packages and offer to the user the question, if ALL these found no more 
wished packages shall now be processed, or if for each package it should 
be asked individually once more;
(5) if in (4) the manual, step wise approval was requested, then ask by 
priority first for the packages found in the first iteration, then for 
the ones found in the next iteration, and so on.
(6) iterate steps (4) to (6) until a final selection is reached which 
should be processed


Any simple 'apt remove package' or 'apt purge package' would no more let 
unwished packages remain in the system, and any 'apt remove 
--keeptimestamp N' or 'apt purge --keeptimestamp N' would set the 
installation of packages back to a pristine state. At least the package 
state right after the initial, successful OS installation is always 
being defined as a pristine state, and alternative pristine stamps could 
any time be defined by the user for any time. Combination of the options 
would be possible, like in: 'apt remove --keeptimestamp 3 packagename'; 
The latter case would protect to remove the package "packagename" if 
this would break the state of time stamp 3.
Splendid!

 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. :-(

[toc] | [prev] | [next] | [standalone]

#222957

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#222965

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.

[toc] | [prev] | [next] | [standalone]

#222978

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#222940

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/

[toc] | [prev] | [next] | [standalone]

#222944

On Sun, 31 May 2020 16:28:34 +0700
Victor Sudakov <vas@sibptus.ru> 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

[toc] | [prev] | [next] | [standalone]

#222945

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | linux.debian.user

csiph-web