Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #222750 > unrolled thread
| Started by | Victor Sudakov <vas@sibptus.ru> |
|---|---|
| First post | 2020-05-27 10:50 +0200 |
| Last post | 2020-06-08 21:40 +0200 |
| Articles | 14 on this page of 94 — 25 participants |
Back to article view | Back to linux.debian.user
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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-05-28 08:10 +0200 |
| Message-ID | <AbjTP-nY-5@gated-at.bofh.it> |
| In reply to | #222781 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Victor Sudakov <vas@sibptus.ru> |
|---|---|
| Date | 2020-05-28 07:30 +0200 |
| Message-ID | <Abjh8-8nA-7@gated-at.bofh.it> |
| In reply to | #222755 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2020-05-27 20:10 +0200 |
| Message-ID | <Ab8F4-21s-5@gated-at.bofh.it> |
| In reply to | #222750 |
On Wed, 27 May 2020 15:47:00 +0700 Victor Sudakov <vas@sibptus.ru> 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/
[toc] | [prev] | [next] | [standalone]
| From | Victor Sudakov <vas@sibptus.ru> |
|---|---|
| Date | 2020-05-28 07:40 +0200 |
| Message-ID | <AbjqO-8qK-9@gated-at.bofh.it> |
| In reply to | #222759 |
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/
[toc] | [prev] | [next] | [standalone]
| From | "Sijmen J. Mulder" <ik@sjmulder.nl> |
|---|---|
| Date | 2020-05-28 11:20 +0200 |
| Message-ID | <AbmRH-28G-1@gated-at.bofh.it> |
| In reply to | #222750 |
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
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-05-28 11:30 +0200 |
| Message-ID | <Abn1n-2c2-9@gated-at.bofh.it> |
| In reply to | #222789 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | emetib <chadbrabec@gmail.com> |
|---|---|
| Date | 2020-06-01 05:10 +0200 |
| Message-ID | <AcIZP-2qI-3@gated-at.bofh.it> |
| In reply to | #222750 |
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
[toc] | [prev] | [next] | [standalone]
| From | Marco Möller <talby@debianlists.mobilxpress.net> |
|---|---|
| Date | 2020-06-01 12:20 +0200 |
| Message-ID | <AcPHX-6pd-1@gated-at.bofh.it> |
| In reply to | #222956 |
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.
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2020-06-01 13:30 +0200 |
| Message-ID | <AcQNI-70G-11@gated-at.bofh.it> |
| In reply to | #222964 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-06-04 16:40 +0200 |
| Message-ID | <AdZcf-7GD-41@gated-at.bofh.it> |
| In reply to | #222964 |
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-<HOSTNAME>-<distribution>-<root-filesystem-partition's-LABEL>/ 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.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-06-04 21:50 +0200 |
| Message-ID | <Ae42d-28b-1@gated-at.bofh.it> |
| In reply to | #223049 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Marco Möller <talby@debianlists.mobilxpress.net> |
|---|---|
| Date | 2020-06-05 13:10 +0200 |
| Message-ID | <Aeioy-2CN-5@gated-at.bofh.it> |
| In reply to | #223057 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-06-06 11:40 +0200 |
| Message-ID | <AeDsZ-139-7@gated-at.bofh.it> |
| In reply to | #223067 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-06-08 21:40 +0200 |
| Message-ID | <AfvMJ-7h-13@gated-at.bofh.it> |
| In reply to | #223111 |
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 "cleaning" scenario, it's simple to copy /var/lib/dpkg/status and /var/lib/apt/extended-states at first boot. In fact, you can copy them (from /target…) when Grub has been installed. (I happen to routinely run a script that save the packages list in five formats, dpkg -l, packages, packages_versions, show-versions and package origins, for cross-comparison with other installations.) Cheers, David.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | linux.debian.user
csiph-web