Hallo Daniel,
Gleichzeitig kannst du ein virtuelles Paket mit immer gleichem Namen
erstellen, ...
in die debian/control.in (via sed o.ä.) eintragen. Mittels /usr/bin/dch
Also ich baue die Pakete mit 'dpkg-deb -b *' und setze die von Dir erwähnten "devscripts" (noch?) nicht ein - das sollte aber erst mal egal sein. Folgen wir mal dem sehr guten meta-package Gedanken:
Ich bauen nun meine Kerne als "priv-kernel-3.0-1", später "priv-kernel-3.0-2" (immer "Package: priv-kernel-3.0" in control) und "priv-kernel-3.0.1-1" sowie "priv-kernel-3.0.1-2" (je "Package: priv-kernel-3.0.1") jeweils in arch "i386" und "amd64". Die Versionen "*-1" zu "*-n" spiegeln nur andere Optionen beim Bauen der Kerne wider, wobei die Versionen "3.0-x" und "3.0.1-x" das vanilla Versionsschema abbilden. Dazu habe ich ein Paket "priv-kernel-3.0" in arch "all" mit "Depends: priv-kernel-3.0". Dieses Paket installiert sollte nun "priv-kernel-3.0-1" fordern. Sobald im repo auch "priv-kernel-3.0-2" ankommt, gibt es ein Update, welches Dateien überschreibt, das wäre gewollt. Wenn mein "priv-kernel-3.0.1-1" erscheint muss ich auch die Abhängigkeit im Metapacket anpassen auf "Depends: priv-kernel-3.0.1" und es gibt für den Client nun "priv-kernel-3.0.1-1" zu installieren, welches den "priv-kernel-3.0" in Ruhe ließe. Soweit zur Theorie ;-)
meinetwegen "mein-kern": apt-cache show equivs. Dort schreibst du auch
Praktisch habe ich Obiges so umzusetzen versucht und nun das Problem, dass der Client das Metapaket gar nicht sieht - im Repo ist es vorhanden. Jetzt schreibst Du von "equivs"; sollte das nicht genau das tun, was ich "manuell" versucht habe? Erscheint mein Paket nicht, weil es "leer" ist?
Mit freundlichen Grüßen / Kind regards Ronny Seffner