Name/Versionsname für Squidpaket

[hamster21]

Servus,

ich möchte aktuell ein Squid mit ssl bauen und im Buster nutzen. Dabei habe ich mich an die Anleitung "SimpleBackportCreation" gehalten, jedoch das Squid-Paket aus Buster genommen. Konkret:

apt source squid
cd squid-4.6
vi debian/rules
--with-openssl \
--enable-ssl-crtd
sudo mk-build-deps --install --remove
dch --newversion 9.0
fakeroot debian/rules binary
dpkg-buildpackage -us -uc

Fehlermeldung:
dpkg-source -b .
dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../squid_9.0.orig.tar.{bz2,gz,lzma,xz}
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 255

die für mich wichtigen Pakete squid und squid-common sind fertig gebaut und nutzbar. Irgendwie scheint es mir trotzdem nicht "richtig" zu sein wie ich hier vorgehe. Das "man dch" hat mir leider keine Erleuchtung gebracht wie ich das Paket korrekt benennen sollte. Pakete bauen ist für mich Neuland; kann gut sein, dass der hier genannte Weg nicht sehr sinnvoll ist...
Ziel wäre es, dass bei Updates im Original-Squid mein Paket nicht automatisch geupdatet wird und ich es entsprechend selbst neu baue/installiere. Vielleicht habt ihr hier einen Hinweis/Tipp für mich wie man es korrekt machen sollte.

Vielen Dank.

[eggy]

Das "man dch" hat mir leider keine Erleuchtung gebracht wie ich das Paket korrekt benennen sollte.

https://www.debian.org/doc/manuals/main ... ml#namever
dch hat nen flag für nächste Version: "dch -i"

Pakete bauen ist für mich Neuland; kann gut sein, dass der hier genannte Weg nicht sehr sinnvoll ist...
Ziel wäre es, dass bei Updates im Original-Squid mein Paket nicht automatisch geupdatet wird und ich es entsprechend selbst neu baue/installiere. Vielleicht habt ihr hier einen Hinweis/Tipp für mich wie man es korrekt machen sollte.

Quick n dirty: Version superhoch setzen, kann/wird daneben gehen. Besser nen eigenen Namen fürs Paket ausdenken und das ursprüngliche Pakete bei in der debian/control als conflict eintragen.

[JTH]

Servus,

Moin.

fakeroot debian/rules binary
dpkg-buildpackage -us -uc

debian/rules binary braucht man nicht von Hand aufrufen, das erledigt dpkg-buildpackage. Für deinen Zweck und auch um den Fehler von dpkg-source -b wegzubekommen:

Code: Alles auswählen

squid-4.6$ dpkg-buildpackage --build=binary --no-sign

oder kurz

Code: Alles auswählen

squid-4.6$ dpkg-buildpackge -b --no-sign

Zu dch kann ich nicht viel sagen. Aber zum Versionsschema für Pakete:

Das sieht neben der Upstreamversion, hier 4.6 von Squid, noch eine vorgestellte Epoch in der Paketversion und eine nachgestellte Debianrevision des Pakets vor (z.B. für kleinere Anpassungen damit das Paket für Debian überhaupt baut).

Die Epoch ist der übliche Weg, um ein Paket, das ansonsten in gleicher Version gebaut ist, zu „verdrängen“. Du könntest z.B. deine Paketversion so aussehen lassen: 1:4.6. Die Squid-Pakete aus dem Debianrepo haben keine Epoch, die wird beim Versionssortieren damit als 0 angenommen. Deine Pakete mit einer 1 vorne haben damit – auch bei einem Upgrade – die höhere Version und bleiben installiert. Auch wenn sich die Upstreamversion von Squid aus dem Debianrepo z.B. von 4.6 zu 4.7 ändert. 1:4.6 gilt dann immer noch als neuer als 4.7.

Falls du damit irgendwelche Abhängigkeitsprobleme von anderen Paketen bekommst, wäre Umbenennen und ein Provides: squid-4.6 in debian/control wahrscheinlich der passendere Weg.

[hamster21]

Vielen dank euch beiden.

Die Variante mit -i die Version nach oben zu ziehen hatte ich auch gesehen, aber aus genau den beschrieben Gründen als nicht optimal angesehen.

"Besser nen eigenen Namen fürs Paket ausdenken und das ursprüngliche Pakete bei in der debian/control als conflict eintragen."
Muss ich mir anschauen, ist Neuland

Das mit der Epoch werde ich gleich ausprobieren, danke für die Erklärung und den Link.

MfG