Hello,

I would like to install many computers with largely the same package
list. To do this, I can use

dpkg --get-selections > packages.lst

to create a list of the installed packages from a computer on which I
have previously installed the standard packages I want, which I can
then implement on other computers with

cat packages.lst | dpkg --set-selections

and

apt-get dselect-upgrade

.

In addition, the extended status of the packages should be adopted,
i.e. whether a package was installed automatically as a dependency of
another, or manually. Therefore, I added a third column with the
extended status to the packages.lst, which normally has the form

<package> <install_status>

per line, so that a line now has the following form:

<package> <install_status> <extended_status>

For a concrete example, it looks like this:

virt-viewer install auto

This works wonderfully when installing a computer, first the packages
are installed as desired and then the extended status is set as desired
- the reverse is not possible because apt-mark does not allow to set
the extended state of a package that is not installed.

However, the packages.lst that is used on computers to be installed
sometimes does not consist of just one file that was created on another
computer, but of several concatenated files which were either created
automatically with dpkg --set-selections or manually. So, it can
happen, for example, that the overall packages.lst created from several
individual packages.lst contains:

.
.
.
virt-manager install manual
.
.
.
virt-viewer install auto
.
.
.
virt-manager purge

(the third column does not have to be present).

This leads to virt-viewer (as a dependency of virt-manager) being
installed and then uninstalled again and again. It would of course be
better if packages with "auto" in the third column are not even
installed, if not needed by another package - does anyone have an idea
how this can be done?

Regards
Christoph




Hallo,

ich möchte viele Rechner mit weitgehend gleicher Paketliste installieren. Dafür 
kann ich von einem Rechner, auf dem ich vorher von mir gewünschte 
Standardpakete installiert habe, mit Hilfe von

dpkg --get-selections > packages.lst

eine Liste der installierten Pakete erstellen, die ich dann auf anderen 
Rechnern mit

cat packages.lst | dpkg --set-selections

und

apt-get dselect-upgrade

realisieren kann.

Zusätzlich soll aber der erweiterte Status der Pakete übernommen werden, also 
ob ein Paket automatisch als Abhängigkeit von einem anderen installiert wurde, 
oder manuell. Daher habe ich in der packages.lst, die normalerweise pro Zeile 
die Form

<package>               <install_status>

hat, noch eine dritte Spalte mit dem erweiterten Status hinzugefügt, so dass 
eine Zeile folgende Form hat:

<package>       <install_status>        <extended_status>

Im konkreten Fall sieht das zum Beispiel so aus:

virt-viewer     install                 auto


Das funktioniert bei der Installation eines Rechners so weit auch ganz 
wunderbar, erst werden die Pakete werden wie gewünscht installiert und dann die 
erweiterten Status wie gewünscht gesetzt - umgekehrt ist es nicht möglich, weil 
apt-mark das Setzen des erweiterten Status eines nicht installierten Pakets 
nicht erlaubt.

Nur besteht die packages.lst, die auf zu installierenden Rechnern angewendet 
wird, manchmal gar nicht nur aus einer Datei, die auf einem anderen Rechner 
erstellt wurde, sondern aus mehreren, hintereinander gehängten Dateien, die 
entweder automatisch mit dpkg --set-selections oder manuell angelegt wurden. 
Dabei kann es z.B. vorkommen, dass in der aus mehreren einzelnen packages.lst 
entstandenen Gesamt-packages.lst steht:

.
.
.
virt-manager    install         manual
.
.
.
virt-viewer     install         auto
.
.
.
virt-manager    purge

(die dritte Spalte muss nicht vorhanden sein).

Das führt dazu, dass virt-viewer immer wieder installiert und dann wieder 
deinstalliert wird. Besser wäre natürlich, wenn Pakete mit "auto" in der 
dritten Spalte und nicht benötigter Abhängigkeit durch ein anderes Paket gar 
nicht erst installiert würden - hat jemand eine Idee, wie sich das 
bewerkstelligen lässt?

Gruß
  Christoph

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to