Re: Question about get-selections
In , Jörg-Volker Peetz wrote: >Besides the discussion about how to preserve the installed packages state, > I would also backup the file /var/cache/debconf/config.dat which helps to > restore the configuration of the configurable installed packages. But I > don't know how to do it automatically. debconf-get-selections and debconf-set-selections are your friends here. I think I mentioned them in an earlier post. debconf-utils: /usr/bin/debconf-get-selections debconf: /usr/bin/debconf-set-selections -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Question about get-selections
Besides the discussion about how to preserve the installed packages state, I would also backup the file /var/cache/debconf/config.dat which helps to restore the configuration of the configurable installed packages. But I don't know how to do it automatically but I think its described in the man page debconf(7) of the debconf-doc package. -- Regards, Jörg-Volker. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
On Fri,01.May.09, 13:49:12, Boyd Stephen Smith Jr. wrote: > Even if you think you do care, you probably do. Either that, or you have a > different goal. That's more likely. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Question about get-selections
In <20090501183939.ga10...@think.homelan>, Andrei Popescu wrote: >On Fri,01.May.09, 13:26:50, Boyd Stephen Smith Jr. wrote: >> Because we are talking about restoring the saved state, and which package >> satisfies an "virtual | package-i-don't-like | package-i-like" >> Depend/Recommend does matter, even if that package is marked automatically >> installed. > >I can't talk for others, but if that package was automatically installed >on my system then I didn't care about possible alternatives ;) You do if the order the alternatives are listed has changed and it confuses the dependency resolver when you are installing. Ideally, this would be so scriptable as to be non-interactive -- which is why I included instructions for saving/restoring debconf data as well. You won't have debconf data for the alternative you didn't have installed, so you will have to configure it when you already have a working configuration for something else. Even if you think you do care, you probably do. Either that, or you have a different goal. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Question about get-selections
On Fri,01.May.09, 13:26:50, Boyd Stephen Smith Jr. wrote: > > Because we are talking about restoring the saved state, and which package > satisfies an "virtual | package-i-don't-like | package-i-like" > Depend/Recommend does matter, even if that package is marked automatically > installed. I can't talk for others, but if that package was automatically installed on my system then I didn't care about possible alternatives ;) Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Question about get-selections
In <20090501074519.gu10...@think.homelan>, Andrei Popescu wrote: >On Thu,30.Apr.09, 20:59:40, J.M.Roth wrote: >> dpkg --get-selections | awk '$2 == "install"' > packagesNG_installed >> aptitude -F '%p' search '~i~M' > packagesNG_autoinstalled > >I'm curious, why not replace these two with > >aptitude -F '%p' search '~i!~M' > packagesNG_not_autoinstalled > >Auto-installed packages are really not important (at least for me) and >they might change from one version to the other of some package. Let >apt/aptitude figure out what additional packages need to be installed, >that's what they were created for. Because we are talking about restoring the saved state, and which package satisfies an "virtual | package-i-don't-like | package-i-like" Depend/Recommend does matter, even if that package is marked automatically installed. It is possible that some of the packages you capture with the dpkg --get- selections end up not being installed at all if the Depends/Recommends change because package versions have moved forward between your save and your restore. However, having them in the "install" and "automatically installed" state gives hints to the dependency resolver about which package(s) you want to satisfy dependencies. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Question about get-selections
On Thu,30.Apr.09, 20:59:40, J.M.Roth wrote: > I have done more experiments and have come up with these notes for now. > > #BACKUP > dpkg --get-selections | awk '$2 == "install"' > packagesNG_installed > aptitude -F '%p' search '~i~M' > packagesNG_autoinstalled I'm curious, why not replace these two with aptitude -F '%p' search '~i!~M' > packagesNG_not_autoinstalled Auto-installed packages are really not important (at least for me) and they might change from one version to the other of some package. Let apt/aptitude figure out what additional packages need to be installed, that's what they were created for. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Question about get-selections
I have done more experiments and have come up with these notes for now. #BACKUP dpkg --get-selections | awk '$2 == "install"' > packagesNG_installed aptitude -F '%p' search '~i~M' > packagesNG_autoinstalled debconf-get-selections | grep -Ev '^[[:space:]]*(#|$)' > packagesNG_debconf # RESTORE # make sure the system is quite up-to-date (sources.list must match old system) aptitude update aptitude upgrade # forget package state dpkg --clear-selections # also forget aptitude's extended states aptitude -F '%p' search '~M' > /tmp/autopacks.$$ xargs -r -- aptitude --schedule-only unmarkauto < /tmp/autopacks.$$ rm /tmp/autopacks.$$ # load the states from backup dpkg --set-selections < packagesNG_installed # load extended states xargs -r -- aptitude --schedule-only markauto < packagesNG_autoinstalled debconf-set-selections < packagesNG_debconf # better let the following run inside a screen aptitude install * ASSERTIONS packages that are installed AND are not going to be removed '~i!~aremove' PLUS packages that will be installed '~ainstall' ( '~i!~aremove | ~ainstall' ) SHOULD EQUAL packages that are installed on source '~i' autoinstall packages should match on source and destination aptitude -F '%p' search '~M' ( | wc -l ) * All of this seems to work, except of course for locally created/obsolete packages and such, which might be indicated by a difference in the package count as mentioned in the previous assertions. Additionally, from a base/fresh install of a Debian system I suppose there would not be many conflicts. On my test system (desktop system to be converted to server system via this method of saved metadata) I have a large negative score for conflict resolution. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
2009/4/24 Paul E Condon : > On 2009-04-23_21:27:07, Daniel Burrows wrote: [snip] >> >> The "state" is a flag indicating the package's current state. It's >> written as an integer because I designed this code when I was young and >> foolish. :-) The relevant values are: The hint was here.. ^^ ...'I designed this code'... $ man aptitide | grep -A1 ^AUTHOR AUTHOR Daniel Burrows [snip] > > Besides get-selections there are other approaches to saving and restoring > the state of the apt system. Are you aware of the documentation package > for aptitude? [snip] cheers, Owen. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
In <20090424055608.gb20...@big.lan.gnu>, Paul E Condon wrote: >In the aptitude-create-state-bundle description, they give a list of > exactly what they (the documenters of the aptitude program no less) > believe to be the sum total of what is needed to recreate a living apt > system. This list is: > >$HOME/.aptitude >/var/lib/aptitude >/var/lib/apt >/var/cache/apt/*.bin >/etc/apt >/var/lib/dpkg/status > >It is not a very long list, but it does include a lot more than merely >a list of installed packages, and, particularly significant for this >thread, it does not include a copy of the output from running >--get-selections. I'm pretty sure dpkg --get-selections is just (part of) the data in /var/lib/dpkg/status, in a different format. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Question about get-selections
On Thu, Apr 23, 2009 at 11:56:08PM -0600, Paul E Condon was heard to say: > Are you aware of the documentation package for aptitude? Yes. :-) Daniel (SCNR) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
On 2009-04-23_21:27:07, Daniel Burrows wrote: > On Thu, Apr 23, 2009 at 09:13:38AM +, "J.M.Roth" > was heard to say: > > > >Oh and I guess to make things really right one would have to use > > > >--get-selections '*' > > > >during the backup, or an additional > > > >dpkg --clear-selections > > > >before the restore. Just a thought. > > > > > > --clear-selections before the restore makes sense. But, any selection > > > other > > > than "install" isn't really necessary to reproduce. > > > > If you consider a base system that you try to restore to some previously > > existing system that you took the backup from, that may be true. But if you > > want > > to 'convert' a generic system to some other system (that you took the backup > > from), it might be necessary to e.g. purge exim4 and install postfix, in > > case > > the package management wouldn't figure that out on its own. > > When I was working on this problem as a part-time sysadmin, I ended > up writing a big "script" for aptitude. You can do this by (ab)using > the ability to enter commands at the aptitude prompt. However, that > doesn't give you the ability to "snapshot" a state easily, > automatically and efficiently. Probably not the greatest idea. > > Another option you could take would be to generate a pkgstates file. > You seem to be familiar with awk, so it shouldn't be hard. All you > need is a bunch of stanzas like this, separated by blank lines: > > Package: cyrus-admin-2.3 > State: 3 > > The "state" is a flag indicating the package's current state. It's > written as an integer because I designed this code when I was young and > foolish. :-) The relevant values are: > > 1 -> Install > 2 -> Hold > 3 -> Remove > 4 -> Purge > > This is the file that "aptitude install" with no arguments uses to > decide what to install. Generating it directly should give you a much > simpler and faster script. > > Similarly, you should be able to generate /var/lib/apt/extended_states > directly. Each stanza there looks like: > > Package: kpat > Auto-Installed: 1 > > where of course "1" is "yes it is auto-installed". You can also have > "0", but that means the same thing as not having a stanza at all for > that package. > > Please note, I haven't tried any of this myself! And of course you'll > be at the mercy of any future changes in file format (not that I know > of any that are planned, and they'd have to be backwards-compatible > anyway...) > > Daniel Besides get-selections there are other approaches to saving and restoring the state of the apt system. Are you aware of the documentation package for aptitude? It is available the many languages as html files in debian packages all ending with a spcific language code. In that package, in the English version anyway, there is documentation of two relevant programs: aptitude-create-state-bundle and aptitude-run-state-bundle The first bundles up what is claimed to be everything that is needed to recreate the current state of the local apt system. The second unbundles the bundly and puts it where it belongs in order to be fully functional. In the aptitude-create-state-bundle description, they give a list of exactly what they (the documenters of the aptitude program no less) believe to be the sum total of what is needed to recreate a living apt system. This list is: $HOME/.aptitude /var/lib/aptitude /var/lib/apt /var/cache/apt/*.bin /etc/apt /var/lib/dpkg/status It is not a very long list, but it does include a lot more than merely a list of installed packages, and, particularly significant for this thread, it does not include a copy of the output from running --get-selections. I think persons who are conserned about how best to use --get-selections output might well study the aptitude document in greater detail than I have. What I have done for my systems is to include these files/directories in my nightly backup of each of my systems. I've sort of subsumed the meat of their idea into a larger backup system. I haven't tested rebuilding a system that crashed and burned form by nightly backups, but I'm sure that I'll be better off with these files than without them if I ever have to rebuild from scratch. HTH -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
On Thu, Apr 23, 2009 at 09:13:38AM +, "J.M.Roth" was heard to say: > > >Oh and I guess to make things really right one would have to use > > >--get-selections '*' > > >during the backup, or an additional > > >dpkg --clear-selections > > >before the restore. Just a thought. > > > > --clear-selections before the restore makes sense. But, any selection > > other > > than "install" isn't really necessary to reproduce. > > If you consider a base system that you try to restore to some previously > existing system that you took the backup from, that may be true. But if you > want > to 'convert' a generic system to some other system (that you took the backup > from), it might be necessary to e.g. purge exim4 and install postfix, in case > the package management wouldn't figure that out on its own. When I was working on this problem as a part-time sysadmin, I ended up writing a big "script" for aptitude. You can do this by (ab)using the ability to enter commands at the aptitude prompt. However, that doesn't give you the ability to "snapshot" a state easily, automatically and efficiently. Probably not the greatest idea. Another option you could take would be to generate a pkgstates file. You seem to be familiar with awk, so it shouldn't be hard. All you need is a bunch of stanzas like this, separated by blank lines: Package: cyrus-admin-2.3 State: 3 The "state" is a flag indicating the package's current state. It's written as an integer because I designed this code when I was young and foolish. :-) The relevant values are: 1 -> Install 2 -> Hold 3 -> Remove 4 -> Purge This is the file that "aptitude install" with no arguments uses to decide what to install. Generating it directly should give you a much simpler and faster script. Similarly, you should be able to generate /var/lib/apt/extended_states directly. Each stanza there looks like: Package: kpat Auto-Installed: 1 where of course "1" is "yes it is auto-installed". You can also have "0", but that means the same thing as not having a stanza at all for that package. Please note, I haven't tried any of this myself! And of course you'll be at the mercy of any future changes in file format (not that I know of any that are planned, and they'd have to be backwards-compatible anyway...) Daniel -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
Boyd Stephen Smith Jr. iguanasuicide.net> writes: > In post.gmane.org>, J.M.Roth wrote: > >Now... I've been playing a little bit with this. > > > >First, I get some > >warning: Unknown type error, skipping line > >using debconf-set-selections < ... > > Hrm, that's somewhat troubling. It won't affect which packages are > installed, but it will affect how they are configured. > > >While that does not worry me much, I get a > >xargs: aptitude: exited with status 255; aborting > >at the end of > >xargs -r -- aptitude markauto < ... > >Probably, this is because conflicts are generated, however there were/are > > no conflicts on the original system. > > > >Of and BTW you had better use: > >#dpkg --get-selections | awk '$2 == "install"' > ... > >(Note the *two* equality signs) I was wondering where all those > > unnecessary conflicts were coming from > > D'oh! I am still testing, and as far as I can see, conflicts are still present on the system I try to restore to, even if the selections are correct... :-\ > http://algebraicthunk.net/~dburrows/blog/entry/a-better-map-of-the-apt- > state-files/ might help. Indeed it does. Thanks :-) > Daniel Burrows I think Mr. Burrows' thoughts about how to restore the packages using its metadata might be interesting. Surely, he must be a busy man. I have now started a thread on the aptitude-devel list, where he seems to be active. > >Oh and I guess to make things really right one would have to use > >--get-selections '*' > >during the backup, or an additional > >dpkg --clear-selections > >before the restore. Just a thought. > > --clear-selections before the restore makes sense. But, any selection other > than "install" isn't really necessary to reproduce. If you consider a base system that you try to restore to some previously existing system that you took the backup from, that may be true. But if you want to 'convert' a generic system to some other system (that you took the backup from), it might be necessary to e.g. purge exim4 and install postfix, in case the package management wouldn't figure that out on its own. I have now mirrored the necessary package files in order to experiment on this issue. I will let you know. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
In , J.M.Roth wrote: >Now... I've been playing a little bit with this. > >First, I get some >warning: Unknown type error, skipping line >using debconf-set-selections < ... Hrm, that's somewhat troubling. It won't affect which packages are installed, but it will affect how they are configured. >While that does not worry me much, I get a >xargs: aptitude: exited with status 255; aborting >at the end of >xargs -r -- aptitude markauto < ... >Probably, this is because conflicts are generated, however there were/are > no conflicts on the original system. > >Of and BTW you had better use: >#dpkg --get-selections | awk '$2 == "install"' > ... >(Note the *two* equality signs) I was wondering where all those > unnecessary conflicts were coming from ;-) D'oh! Sorry, my awk skills are still growing, and I didn't thoroughly test the actions I proposed. >I need to say that sometimes I feel a bit dazzled by all these tools >dselect >dpkg >apt-get >aptitude http://algebraicthunk.net/~dburrows/blog/entry/a-better-map-of-the-apt- state-files/ might help. Daniel Burrows does a lot of aptitude development so you might get some more good information by following his blog http://algebraicthunk.net/~dburrows/blog/ which is also aggregated on planet Debian http://planet.debian.net/ . > I guess the > auto flag of aptitude is exclusive to aptitude, otherwise we would not > have to set it manually. Yes. Although you *could* set it after you complete the install part of the restore. If aptitude needs to change your selections, though, it helps the resolver to know if something was automatically installed. >Oh and I guess to make things really right one would have to use >--get-selections '*' >during the backup, or an additional >dpkg --clear-selections >before the restore. Just a thought. --clear-selections before the restore makes sense. But, any selection other than "install" isn't really necessary to reproduce. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Question about get-selections
Boyd Stephen Smith Jr. iguanasuicide.net> writes: > >I'd rather do > >aptitude -F '%p' search '~i~M' > auto_installed_packages > >Your command does not work if the package state is e.g. 'i A' > >(note the space) > > Actually, it only works in that case. Of course, because of the search > terms, all the packages will have status 'i A'. That's what I meant. Now... I've been playing a little bit with this. First, I get some warning: Unknown type error, skipping line using debconf-set-selections < ... While that does not worry me much, I get a xargs: aptitude: exited with status 255; aborting at the end of xargs -r -- aptitude markauto < ... Probably, this is because conflicts are generated, however there were/are no conflicts on the original system. Of and BTW you had better use: #dpkg --get-selections | awk '$2 == "install"' > ... (Note the *two* equality signs) I was wondering where all those unnecessary conflicts were coming from ;-) I need to say that sometimes I feel a bit dazzled by all these tools dselect dpkg apt-get aptitude After a dpkg --set-selections I have to use 'apt-get dselect-upgrade' instead of 'apt-get upgrade'. However, the standard 'aptitude install' works fine and seems to know about the --set-selections. I am not clear what kind of information is available to what kind of tool. I guess the auto flag of aptitude is exclusive to aptitude, otherwise we would not have to set it manually. I guess one has got to have the overview over all that first ~.~ Oh and I guess to make things really right one would have to use --get-selections '*' during the backup, or an additional dpkg --clear-selections before the restore. Just a thought. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
In , J.M.Roth wrote:
>Boyd Stephen Smith Jr. iguanasuicide.net> writes:
>> aptitude search '~i~M' | awk '{print $3}' > auto_installed_packages
>
>I'd rather do
>aptitude -F '%p' search '~i~M' > auto_installed_packages
>Your command does not work if the package state is e.g. 'i A'
>(note the space)
Actually, it only works in that case. Of course, because of the search
terms, all the packages will have status 'i A'.
Still, your command saves a fork, which makes it better in my book.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: Question about get-selections
Boyd Stephen Smith Jr. iguanasuicide.net> writes:
>
> On Thursday 26 March 2009 22:09:28 Paul E Condon wrote:
> >Your suggestion does raise in interesting issue: given a set of
> >installed packages in a --get-selections file, and given that the
> >dependency information is available in the packages, what is the
> >minimum set of install commands to aptitude that will reconsturct the
> >installation from scratch?
That issue still interests me, as far as a final and official
solution is concerned.
> To save the state of the Debian packages installed:
> dpkg --get-selections | \
> awk '$2 = "install"' > installed_package_selections
> aptitude search '~i~M' | awk '{print $3}' > auto_installed_packages
I'd rather do
aptitude -F '%p' search '~i~M' > auto_installed_packages
Your command does not work if the package state is e.g. 'i A'
(note the space)
And as I said: please keep me posted on this :)
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
2009/3/28 Paul E Condon : > I'm convinced that the suggestion is worthwhile, but I'm having > difficulty following it. See below. > > On 2009-03-27_16:33:11, Owen Townend wrote: >> 2009/3/27 Paul E Condon : >> > On 2009-03-26_19:08:32, Douglas A. Tutty wrote: >> >> >> >> Many of those packages will have been installed automatically by your >> >> package manager. ??If you use aptitude, you only need to record the >> >> packages which you manually installed: >> >> >> >> aptitude search `~i!~M' >> >> >> >> You can then install them, then aptitude will automatically install what >> >> is needed by them. >> >> >> [snip] >> > >> > Well, I may sound like an orderly person, but writing down a record of >> > each time I install something is rather more orderly than I think I >> > can ever be. ??I'm looking to program the computer to keep track of me. >> >> I think you misunderstood his suggestion, it is a method of automating >> the process... >> >> > >> > Your suggestion does raise in interesting issue: given a set of >> > installed packages in a --get-selections file, and given that the >> > dependency information is available in the packages, what is the >> > minimum set of install commands to aptitude that will reconsturct the >> > installation from scratch? Does anyone know a way to solve this >> > problem? It might be a rather difficult search problem, but it might >> > be there is some neat trick. Does anyone here know? >> > >> > I guess I could somehow search the apt system for packages that are not >> > in the depends list of any other package, but I think there are cycles >> > in the dependency linkages. The way it is used, there is no reason to >> > demand that the linkage network be free of cycles, like is required of >> > the directory tree in a file system. >> >> If you follow Douglas' suggestion above it will help in this regard. >> `$ aptitude search '~i!M'` says 'return to me the list of packages >> that are installed but aren't just dependancies or suggestions (marked >> as automatically installed)'. >> >> When you then go to restore, re-install or clone your system you can let >> aptitude figure out the dependencies for itself. >> If you use --get-selections then _all_ of those packages will be marked >> as manually installed on the new system and will _never_ be >> automatically removed as 'just' dependancies. >> >> Example summary of Douglas' solution as I understood it: >> 1) Schedule `aptitude search '~i!M' > /usr/local/backup/package_list` > ^^^ > I ran this manually, and got a long list of packages. Most of the lines > began with "i A ". I tried running: > aptitude search '~i!A' > which seemed more reasonable from my limited intuition. That also gave > mostly lines beginning with "i A ". What am I missing? The documentation > seems very through, but I can't find mention of '!'. I guess it means > 'not', wouldn't have known it was available from scanning the docs. Does > it mean 'not'? [snip] Sorry, my mistake, there was a typo, the above instead gave you a list of every installed package with an 'm' in the title... It should have been: aptitude search '~i!~M' There is a comprehensive list of available search terms here: http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03s05.html The ones used above were these: "~i Select installed packages." "!pattern Select any package that does not match pattern." "~M Select packages that were automatically installed." cheers, Owen. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
In <20090327195314.gt29...@swansys>, green wrote: >Paul E Condon wrote at 2009-03-27 09:26 -0600: >> Now, the discussion has moved to how to query the packaging system to >> get the most useful file of information. I'm still not sure what the >> query string should be. I think the most useful one is probably '~i|~c', which shows any package that is not completely uninstalled (including ones that just have configuration files hanging around). >Restoring the package set is not so simple as restoring the packages that > are manually selected as installed. There are at least these reasons: > >- virtual packages or 'OR' dependencies >- 'recommends' dependencies I'm not sure what the third one is, but the commands I posted in a reply that broke threading should handle both of those well. I will have to look into aptitude-create-state-bundle. I'm fairly sure that's mostly meant when you want to save your requested actions as well. For example, if the dependency resolver crashes or does something "stupid" that you'd like a developer to analyze (and possibly fix). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Question about get-selections
Sorry for breaking the thread. I was having sendmail troubles yesterday due to an ISP switch. :( -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Question about get-selections - a little story
Paul E Condon wrote at 2009-03-27 18:14 -0600: > Recently I agreed to acquire a backtrace using gdb on > gnome-terminal. I had reported it crashing under a certain > situation. I'm not skilled at debugging, but gnome-terminal is > important to me, so I agreed. The work did not go well. Things went > from mildly annoying to bad, and then to very bad, and to much > worse. I reached a point where my system was unusable. So unusable > that I could not ask for help via email. > > This project of making re-installation less difficult is being done in > the expectation that I will crash my system again while helping to > find a bug in software that is important to me. If I do this project > well, I'm sure it will help others to see there way clear to helping > Debian in debugging user reported bugs. Certainly, and hopefully you will have a (long) while to do the project well before the scenario in the first quoted paragraph above happens again! ;) signature.asc Description: Digital signature
Re: Question about get-selections - a little story
On 2009-03-27_17:43:22, green wrote: > Paul E Condon wrote at 2009-03-27 16:35 -0600: > > On 2009-03-27_13:53:14, green wrote: > > > I think I have minimally tested these commands, but it has been a while. > > > It > > > would be great if someone could try this out and add a wiki page for it. ... > > want an exact restore because there might have been security fixes > > released that I would want to include in the new system. > > Well, I have just tried to think of all the possible problems. > In the time I have used Debian, I don't recall ever having needed to do a > reinstall (hence the 'minimally tested'). Every install has been a new one > for > a system on which Debian has not yet been run. Of course this could be > applied > to that even also I suppose... Recently I agreed to acquire a backtrace using gdb on gnome-terminal. I had reported it crashing under a certain situation. I'm not skilled at debugging, but gnome-terminal is important to me, so I agreed. The work did not go well. Things went from mildly annoying to bad, and then to very bad, and to much worse. I reached a point where my system was unusable. So unusable that I could not ask for help via email. This project of making re-installation less difficult is being done in the expectation that I will crash my system again while helping to find a bug in software that is important to me. If I do this project well, I'm sure it will help others to see there way clear to helping Debian in debugging user reported bugs. -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
Paul E Condon wrote at 2009-03-27 16:35 -0600: > On 2009-03-27_13:53:14, green wrote: > > I think I have minimally tested these commands, but it has been a while. > > It > > would be great if someone could try this out and add a wiki page for it. > > Well, I'm going to try it out, I can't promise a wiki that anyone would care > to > look at. We'll see how it goes... Sounds acceptable. :) > > Of course, it would likely help to restore a /etc/apt backup before doing > > any > > of the restore commands. Obviously a different sources.list would cause > > problems. > > In my idea of a good backup, I take a complete copy of all of /etc, so I > already > am getting all of /etc/apt, as well as my exim4 configs, and all the other > stuff > for which it is easy to forget the details under the pressure of a disaster > recovery situation. So /etc/apt seemed a natural place to put the selections, > but > Andrei has another good idea. I use /var/local/backups because I backup /var; to each his own of course. Without some of the obviously unnecessary (and large) portions (found with ncdu), mine is about 0.4G. > > Lastly, I don't think it is possible to restore the package set perfectly > > if > > much time has passed between the backup and the restore, because of changes > > in > > package versions; the more time passes, the more the package set will have > > to > > change for a restore. This is why I have added the backup command that > > saves > > the versions for all installed packages. The only way to get around this > > is to > > have a backup of debs for ALL installed packages. > > I think you are too demanding. Your standards of automation are too > high. When I think of an automatic restore, I think of it being a > situation where my system was distroyed or corrupted while I was away > from home. The time lapse from the last time the system was working > properly (and the last backup was made) until I try to restore is a > few hours to a few months. In the case of a few months, I might not > want an exact restore because there might have been security fixes > released that I would want to include in the new system. Well, I have just tried to think of all the possible problems. In the time I have used Debian, I don't recall ever having needed to do a reinstall (hence the 'minimally tested'). Every install has been a new one for a system on which Debian has not yet been run. Of course this could be applied to that even also I suppose... signature.asc Description: Digital signature
Re: Question about get-selections
On 2009-03-27_13:53:14, green wrote: > Paul E Condon wrote at 2009-03-27 09:26 -0600: > > Now, the discussion has moved to how to query the packaging system to > > get the most useful file of information. I'm still not sure what the > > query string should be. > > Restoring the package set is not so simple as restoring the packages that are > manually selected as installed. There are at least these reasons: I had not thought it possible to do an automatic total restore. What I was hoping for was a reliable list of installed packages that would be a guide to a manual restore that did not leave out anything that turned out to be important to me. But you seem to be onto something much more than I hoped for. > > - virtual packages or 'OR' dependencies > Package 'ilohamail' depends on 'postfix | mail-transport-agent' so package > 'exim4' (or another mail server) may be set as automatically installed. If a > list of manually installed packages is used, aptitude may select 'postfix' > instead of 'exim4' to satisfy that dependency. > > - 'recommends' dependencies > That some package 'ilohamail' recommends 'gnupg' and 'aspell'. The user has > the option of using that or not, and aptitude has a config option for it too. > > If the user allows 'aspell' to be installed automatically, then it may or not > be installed when a list of manually installed packages is used, depending on > the user of the -r or -R flags. Either way, either a package is installed > automatically that was not before, or a package is not installed that was > before. > > > So, one must do backups slightly differently. Here are the commands that I > use: > > # Save aptitude state bundle > aptitude-create-state-bundle state.tar.bz2 > # Save a list of all installed packages > aptitude -F "%?p" --disable-columns search \~i >| installed-all > # Save a list of all installed packages with their versions > aptitude -F "%?p=%?V" --disable-columns search \~i >| installed-all-ver > # Save a list of all automatically installed packages > aptitude -F "%?p" --disable-columns search \~i\~M >| installed-auto > > > Here are the commands I have saved for restoring from the aforementioned > backups: > > # Install all essential, important, required, or standard packages > aptitude -R --schedule-only install $( aptitude -F "%?p" search > \!\~i?or(\~E,\~pimportant,\~prequired,\~pstandard) ) > # Mark as manually installed all essential, important, required, or standard > priority packages > aptitude -R --schedule-only unmarkauto $( aptitude -F "%?p" search > \~i?or(\~E,\~pimportant,\~prequired,\~pstandard) ) > # Mark as automatically installed all packages that are not essential, > important, required, or standard priority > aptitude --schedule-only markauto $( aptitude -F "%?p" search > \~i\!\~E\!\~pimportant\!\~prequired\!\~pstandard ) > # Install all the packages in the installed package list (manual + automatic) > aptitude -R --schedule-only install $( cat installed-all ) > # Select specific versions of packages (you may want to skip this step) > aptitude -R --schedule-only install $( cat installed-all-ver ) > # Mark as automatically installed all packages in that list > aptitude --schedule-only markauto $( cat installed-auto ) > # Run aptitude, check scheduled actions, and apply > aptitude > It will take me a while to understand your process steps, but this really looks interesting. Give me some time to absorb it. Thanks > > I think I have minimally tested these commands, but it has been a while. It > would be great if someone could try this out and add a wiki page for it. Well, I'm going to try it out, I can't promise a wiki that anyone would care to look at. We'll see how it goes... > > > Of course, it would likely help to restore a /etc/apt backup before doing any > of the restore commands. Obviously a different sources.list would cause > problems. In my idea of a good backup, I take a complete copy of all of /etc, so I already am getting all of /etc/apt, as well as my exim4 configs, and all the other stuff for which it is easy to forget the details under the pressure of a disaster recovery situation. So /etc/apt seemed a natural place to put the selections, but Andrei has another good idea. > > Lastly, I don't think it is possible to restore the package set perfectly if > much time has passed between the backup and the restore, because of changes > in > package versions; the more time passes, the more the package set will have to > change for a restore. This is why I have added the backup command that saves > the versions for all installed packages. The only way to get around this is > to > have a backup of debs for ALL installed packages. > I think you are too demanding. Your standards of automation are too high. When I think of an automatic restore, I think of it being a situation where my system was distroyed or corrupted while I was away from home. The time lapse from the last time the sy
Re: Question about get-selections
On Fri,27.Mar.09, 09:26:59, Paul E Condon wrote:
> I see you have a different search string than has been mentioned before.
> Is yours really what you use, or something typed from memory? The ones
> I have tried didn't seem to give correct results.
It was from memory, and I was even right ;)
Let me explain, it's very simple:
~i - select all installed packages
~M - select all automatically installed packages
! - 'not' logical operator
You are obviously not interested in 'not-installed' packages so the only
possible combinations are
!~M~i
or
~i!~M
which will have the same effect (yes, I tested). Because you run this
into a shell the pattern has to be between quotes as some of those
characters ("!" I think) have special meanings.
> In my original thinking, I was mentioning /etc/apt/, because I presumed
> it was a safe place to leave such information. I'm sure there is such a
> safe place, somewhere. You use ~/bak, which I might imitate, now that I
> am aware of it, even if /etc/apt/ is also a safe place.
Aware of? I just created it ;) My philosophy is "keep things at their
default settings as much as possible". This also involves not spreading
unnecessary files across the entire filesystem, /home is the place for
that.
> Now, the discussion has moved to how to query the packaging system to
> get the most useful file of information. I'm still not sure what the
> query string should be.
See above.
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
signature.asc
Description: Digital signature
Re: Question about get-selections
Paul E Condon wrote at 2009-03-27 09:26 -0600: > Now, the discussion has moved to how to query the packaging system to > get the most useful file of information. I'm still not sure what the > query string should be. Restoring the package set is not so simple as restoring the packages that are manually selected as installed. There are at least these reasons: - virtual packages or 'OR' dependencies Package 'ilohamail' depends on 'postfix | mail-transport-agent' so package 'exim4' (or another mail server) may be set as automatically installed. If a list of manually installed packages is used, aptitude may select 'postfix' instead of 'exim4' to satisfy that dependency. - 'recommends' dependencies That some package 'ilohamail' recommends 'gnupg' and 'aspell'. The user has the option of using that or not, and aptitude has a config option for it too. If the user allows 'aspell' to be installed automatically, then it may or not be installed when a list of manually installed packages is used, depending on the user of the -r or -R flags. Either way, either a package is installed automatically that was not before, or a package is not installed that was before. So, one must do backups slightly differently. Here are the commands that I use: # Save aptitude state bundle aptitude-create-state-bundle state.tar.bz2 # Save a list of all installed packages aptitude -F "%?p" --disable-columns search \~i >| installed-all # Save a list of all installed packages with their versions aptitude -F "%?p=%?V" --disable-columns search \~i >| installed-all-ver # Save a list of all automatically installed packages aptitude -F "%?p" --disable-columns search \~i\~M >| installed-auto Here are the commands I have saved for restoring from the aforementioned backups: # Install all essential, important, required, or standard packages aptitude -R --schedule-only install $( aptitude -F "%?p" search \!\~i?or(\~E,\~pimportant,\~prequired,\~pstandard) ) # Mark as manually installed all essential, important, required, or standard priority packages aptitude -R --schedule-only unmarkauto $( aptitude -F "%?p" search \~i?or(\~E,\~pimportant,\~prequired,\~pstandard) ) # Mark as automatically installed all packages that are not essential, important, required, or standard priority aptitude --schedule-only markauto $( aptitude -F "%?p" search \~i\!\~E\!\~pimportant\!\~prequired\!\~pstandard ) # Install all the packages in the installed package list (manual + automatic) aptitude -R --schedule-only install $( cat installed-all ) # Select specific versions of packages (you may want to skip this step) aptitude -R --schedule-only install $( cat installed-all-ver ) # Mark as automatically installed all packages in that list aptitude --schedule-only markauto $( cat installed-auto ) # Run aptitude, check scheduled actions, and apply aptitude I think I have minimally tested these commands, but it has been a while. It would be great if someone could try this out and add a wiki page for it. Of course, it would likely help to restore a /etc/apt backup before doing any of the restore commands. Obviously a different sources.list would cause problems. Lastly, I don't think it is possible to restore the package set perfectly if much time has passed between the backup and the restore, because of changes in package versions; the more time passes, the more the package set will have to change for a restore. This is why I have added the backup command that saves the versions for all installed packages. The only way to get around this is to have a backup of debs for ALL installed packages. signature.asc Description: Digital signature
Re: Question about get-selections
On 2009-03-27_11:19:29, Andrei Popescu wrote: > On Thu,26.Mar.09, 19:08:32, Douglas A. Tutty wrote: > > > I wouldn't put my backup info in /etc/apt. Most of what is in /etc/ > > (just like the rest of the file system) is managed by packages which are > > managed by apt. You may find that what you put in /etc/apt gets changed > > (I don't know, but I wouldn't risk it). > > I doubt that. It would be a *serious* bug to do it! You could test it > like this: > > - install a package with it's own config directory in /etc > - create an arbitrary file in that directory > - *purge* the package > > now dpkg will delete all files it knows about, but will *not* delete the > directory and will issue a warning that it is not empty and couldn't be > deleted. (This is all from memory, there might be minor differences). > > > I keep my backups in /var/local/backup. > > Whereas /var is more likely to be affected (though I doubt any package > would have a reason to touch /var/local/backup). > > Back to the OP's question, I keep my 'aptitude !~M~i' list in ~/bak > especially since /home is backed up anyway ;) > > Regards, > Andrei Andrei, Also, the package that supervises the contents of /etc/apt/ is, I think, dpkg. I'm not sure, but whatever it is, if I were to purge the package that does put config files in /etc/apt/ - - - Wouldn't recovery from that error be far more costly than merely the loss of my goofy little selections list? Packages as important as the one in question do not 'automatically' get purged, I think. I see you have a different search string than has been mentioned before. Is yours really what you use, or something typed from memory? The ones I have tried didn't seem to give correct results. In my original thinking, I was mentioning /etc/apt/, because I presumed it was a safe place to leave such information. I'm sure there is such a safe place, somewhere. You use ~/bak, which I might imitate, now that I am aware of it, even if /etc/apt/ is also a safe place. Now, the discussion has moved to how to query the packaging system to get the most useful file of information. I'm still not sure what the query string should be. -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
I'm convinced that the suggestion is worthwhile, but I'm having difficulty following it. See below. On 2009-03-27_16:33:11, Owen Townend wrote: > 2009/3/27 Paul E Condon : > > On 2009-03-26_19:08:32, Douglas A. Tutty wrote: > >> > >> Many of those packages will have been installed automatically by your > >> package manager. ??If you use aptitude, you only need to record the > >> packages which you manually installed: > >> > >> aptitude search `~i!~M' > >> > >> You can then install them, then aptitude will automatically install what > >> is needed by them. > >> > [snip] > > > > Well, I may sound like an orderly person, but writing down a record of > > each time I install something is rather more orderly than I think I > > can ever be. ??I'm looking to program the computer to keep track of me. > > I think you misunderstood his suggestion, it is a method of automating > the process... > > > > > Your suggestion does raise in interesting issue: given a set of > > installed packages in a --get-selections file, and given that the > > dependency information is available in the packages, what is the > > minimum set of install commands to aptitude that will reconsturct the > > installation from scratch? Does anyone know a way to solve this > > problem? It might be a rather difficult search problem, but it might > > be there is some neat trick. Does anyone here know? > > > > I guess I could somehow search the apt system for packages that are not > > in the depends list of any other package, but I think there are cycles > > in the dependency linkages. The way it is used, there is no reason to > > demand that the linkage network be free of cycles, like is required of > > the directory tree in a file system. > > If you follow Douglas' suggestion above it will help in this regard. > `$ aptitude search '~i!M'` says 'return to me the list of packages > that are installed but aren't just dependancies or suggestions (marked > as automatically installed)'. > > When you then go to restore, re-install or clone your system you can let > aptitude figure out the dependencies for itself. > If you use --get-selections then _all_ of those packages will be marked > as manually installed on the new system and will _never_ be > automatically removed as 'just' dependancies. > > Example summary of Douglas' solution as I understood it: > 1) Schedule `aptitude search '~i!M' > /usr/local/backup/package_list` ^^^ I ran this manually, and got a long list of packages. Most of the lines began with "i A ". I tried running: aptitude search '~i!A' which seemed more reasonable from my limited intuition. That also gave mostly lines beginning with "i A ". What am I missing? The documentation seems very through, but I can't find mention of '!'. I guess it means 'not', wouldn't have known it was available from scanning the docs. Does it mean 'not'? I used aptitude to install the aptitude-doc-en package, but I haven't found where aptitude put the documentation. Where does packaged documentation go under the apt system? It should all be in one place, shouldn't it? What I know about aptitude search comes from googling, and what I find there is no doubt incomplete and obsolete. TIA -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
On Thu,26.Mar.09, 19:08:32, Douglas A. Tutty wrote: > I wouldn't put my backup info in /etc/apt. Most of what is in /etc/ > (just like the rest of the file system) is managed by packages which are > managed by apt. You may find that what you put in /etc/apt gets changed > (I don't know, but I wouldn't risk it). I doubt that. It would be a *serious* bug to do it! You could test it like this: - install a package with it's own config directory in /etc - create an arbitrary file in that directory - *purge* the package now dpkg will delete all files it knows about, but will *not* delete the directory and will issue a warning that it is not empty and couldn't be deleted. (This is all from memory, there might be minor differences). > I keep my backups in /var/local/backup. Whereas /var is more likely to be affected (though I doubt any package would have a reason to touch /var/local/backup). Back to the OP's question, I keep my 'aptitude !~M~i' list in ~/bak especially since /home is backed up anyway ;) Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Question about get-selections
On Thursday 26 March 2009 22:09:28 Paul E Condon wrote:
>On 2009-03-26_19:08:32, Douglas A. Tutty wrote:
>> On Thu, Mar 26, 2009 at 04:26:12PM -0600, Paul E Condon wrote:
>> > But I think I would like to have a record of what packages were
>> > actually installed. So I'm thinking of writing a script, to be run
>> > nightly, that puts a fresh copy of my selections in /etc/apt, e.g.
>> >
>> > # dpkg --get-selections >/etc/apt/selections
>> Many of those packages will have been installed automatically by your
>> package manager. If you use aptitude, you only need to record the
>> packages which you manually installed:
>>
>> aptitude search `~i!~M'
>>
>> You can then install them, then aptitude will automatically install what
>> is needed by them.
>Well, I may sound like an orderly person, but writing down a record of
>each time I install something is rather more orderly than I think I
>can ever be. I'm looking to program the computer to keep track of me.
>
>Your suggestion does raise in interesting issue: given a set of
>installed packages in a --get-selections file, and given that the
>dependency information is available in the packages, what is the
>minimum set of install commands to aptitude that will reconsturct the
>installation from scratch? Does anyone know a way to solve this
>problem? It might be a rather difficult search problem, but it might
>be there is some neat trick. Does anyone here know?
I don't *know* this works, but it should.
To save the state of the Debian packages installed:
dpkg --get-selections | \
awk '$2 = "install"' > installed_package_selections
aptitude search '~i~M' | awk '{print $3}' > auto_installed_packages
debconf-get-selections | grep -Ev '^[[:space:]]*(#|$)' > debconf_settings
To restore the state of the Debian packages installed:
dpkg --set-selections < installed_package_selections
debconf-set-selections < debconf_settings
xargs -r -- aptitude markauto < auto_installed_packages
aptitude install
You may want to throw an aptitude update in there somewhere. You'll still
need to restore any configuration settings that aren't managed by debconf.[1]
The saving can be mostly done as a non-root user, the only thing that will
miss is the "passwords" database, because it is 600 root:root, but running
debconf-get-selections as root will get that, too. Of course, all the
restoring must be done as root.
dpkg says you'll need these packages:
dpkg: /usr/bin/dpkg
aptitude: /usr/bin/aptitude
debconf-utils: /usr/bin/debconf-get-selections
grep: /bin/grep
debconf: /usr/bin/debconf-set-selections
findutils: /usr/bin/xargs
plus one of:
mawk: /usr/bin/mawk
gawk: /usr/bin/gawk
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
[1] In particular, you probably want to restore a backup of the /etc/apt
directory first, so the aptitude run behaves the way it should.
signature.asc
Description: This is a digitally signed message part.
Re: Question about get-selections
2009/3/27 Paul E Condon : > On 2009-03-26_19:08:32, Douglas A. Tutty wrote: >> >> Many of those packages will have been installed automatically by your >> package manager. If you use aptitude, you only need to record the >> packages which you manually installed: >> >> aptitude search `~i!~M' >> >> You can then install them, then aptitude will automatically install what >> is needed by them. >> [snip] > > Well, I may sound like an orderly person, but writing down a record of > each time I install something is rather more orderly than I think I > can ever be. I'm looking to program the computer to keep track of me. I think you misunderstood his suggestion, it is a method of automating the process... > > Your suggestion does raise in interesting issue: given a set of > installed packages in a --get-selections file, and given that the > dependency information is available in the packages, what is the > minimum set of install commands to aptitude that will reconsturct the > installation from scratch? Does anyone know a way to solve this > problem? It might be a rather difficult search problem, but it might > be there is some neat trick. Does anyone here know? > > I guess I could somehow search the apt system for packages that are not > in the depends list of any other package, but I think there are cycles > in the dependency linkages. The way it is used, there is no reason to > demand that the linkage network be free of cycles, like is required of > the directory tree in a file system. If you follow Douglas' suggestion above it will help in this regard. `$ aptitude search '~i!M'` says 'return to me the list of packages that are installed but aren't just dependancies or suggestions (marked as automatically installed)'. When you then go to restore, re-install or clone your system you can let aptitude figure out the dependencies for itself. If you use --get-selections then _all_ of those packages will be marked as manually installed on the new system and will _never_ be automatically removed as 'just' dependancies. Example summary of Douglas' solution as I understood it: 1) Schedule `aptitude search '~i!M' > /usr/local/backup/package_list` (see 'cron') 2) Alter your usual backup program to include the created list file and/or Schedule scp/rsync/ftp/... to copy the list to your backup location. cheers, Owen. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
On 2009-03-26_19:08:32, Douglas A. Tutty wrote: > On Thu, Mar 26, 2009 at 04:26:12PM -0600, Paul E Condon wrote: > > > But I think I would like to have a record of what packages were > > actually installed. So I'm thinking of writing a script, to be run > > nightly, that puts a fresh copy of my selections in /etc/apt, e.g. > > > > # dpkg --get-selections >/etc/apt/selections > > Many of those packages will have been installed automatically by your > package manager. If you use aptitude, you only need to record the > packages which you manually installed: > > aptitude search `~i!~M' > > You can then install them, then aptitude will automatically install what > is needed by them. > > I wouldn't put my backup info in /etc/apt. Most of what is in /etc/ > (just like the rest of the file system) is managed by packages which are > managed by apt. You may find that what you put in /etc/apt gets changed > (I don't know, but I wouldn't risk it). > > I keep my backups in /var/local/backup. > > Your remote script can run a local script to create the backups, then > rsync what you want to the remote (or any other) box. > > Doug. Well, I may sound like an orderly person, but writing down a record of each time I install something is rather more orderly than I think I can ever be. I'm looking to program the computer to keep track of me. Your suggestion does raise in interesting issue: given a set of installed packages in a --get-selections file, and given that the dependency information is available in the packages, what is the minimum set of install commands to aptitude that will reconsturct the installation from scratch? Does anyone know a way to solve this problem? It might be a rather difficult search problem, but it might be there is some neat trick. Does anyone here know? I guess I could somehow search the apt system for packages that are not in the depends list of any other package, but I think there are cycles in the dependency linkages. The way it is used, there is no reason to demand that the linkage network be free of cycles, like is required of the directory tree in a file system. Thanks, -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about get-selections
On Thu, Mar 26, 2009 at 04:26:12PM -0600, Paul E Condon wrote: > But I think I would like to have a record of what packages were > actually installed. So I'm thinking of writing a script, to be run > nightly, that puts a fresh copy of my selections in /etc/apt, e.g. > > # dpkg --get-selections >/etc/apt/selections Many of those packages will have been installed automatically by your package manager. If you use aptitude, you only need to record the packages which you manually installed: aptitude search `~i!~M' You can then install them, then aptitude will automatically install what is needed by them. I wouldn't put my backup info in /etc/apt. Most of what is in /etc/ (just like the rest of the file system) is managed by packages which are managed by apt. You may find that what you put in /etc/apt gets changed (I don't know, but I wouldn't risk it). I keep my backups in /var/local/backup. Your remote script can run a local script to create the backups, then rsync what you want to the remote (or any other) box. Doug. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Question about get-selections
I'm setting up a nightly backup system for my computer. Of course, I want to backup /home/pec and /etc . but I don't think there is any point in backing up all the wonderful Debian packages that are stored in /var . I reason that if something were to cause damage to the package collection in /var it would be much better to download them again from a mirror than to use my own backup, which is likely to be somewhat out of date, and may contain a package that contains the bug that caused my problems. But I think I would like to have a record of what packages were actually installed. So I'm thinking of writing a script, to be run nightly, that puts a fresh copy of my selections in /etc/apt, e.g. # dpkg --get-selections >/etc/apt/selections But my current plans are to have the backup system running from a remote computer and coming in and grabbing the data over the ethernet. So my question: Is one of the many scripts that are part of a standard Debian system nightly backup already making a fresh daily copy of the selections and stashing somewhere (perhaps in var?) ? TIA -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
