Kann mir jemand erklären, warum seit dem Update auf die 5.3 die Paketlisten mit Zahlen und Doppelpunkete übersäht sind. Zum anschauen macht einfach Pirut auf und geht auf Liste -> Alle Pakete und scrollt mal nach unten. Bsp. 1:combat-glibc-headers-2.3-4-2.26.i386
Dies ist kein Pirut Problem, da bei der Installation dies auch schon so ist. Ich habe echt schon viele Dateien durch gesehen, konnte aber bis jetzt nichts finden. Dieses Problem haben alle Redhat Ableger. Ich kann noch nicht einmal ein Bugreport schreiben, da ich nicht den Teil kenne, der dafür verantwortlich ist.
Ich würde gerne diesen Pfusch beseitigen.
Am Samstag, den 11.07.2009, 20:24 +0200 schrieb Ronny Köpsel:
Kann mir jemand erklären, warum seit dem Update auf die 5.3 die Paketlisten mit Zahlen und Doppelpunkete übersäht sind. Zum anschauen macht einfach Pirut auf und geht auf Liste -> Alle Pakete und scrollt mal nach unten. Bsp. 1:combat-glibc-headers-2.3-4-2.26.i386
Dies ist kein Pirut Problem, da bei der Installation dies auch schon so ist. Ich habe echt schon viele Dateien durch gesehen, konnte aber bis jetzt nichts finden. Dieses Problem haben alle Redhat Ableger. Ich kann noch nicht einmal ein Bugreport schreiben, da ich nicht den Teil kenne, der dafür verantwortlich ist.
Ich würde gerne diesen Pfusch beseitigen.
Das ist das RPM Feld "Epoch". Siehe: http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html. Wenn epoch nicht 0 ist wird es angezeigt. In yum sieht das dann so aus:
compat-glibc-headers.x86_64 1:2.3.4-2.26 base
Es handelt sich hier um Pirut bug das epoch vor dem Namen und nicht vor der Version gezeigt wird.
P.S.: comBat-glibc-headers hätte ich auch gerne ;)
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Christoph Maser schrieb:
Am Samstag, den 11.07.2009, 20:24 +0200 schrieb Ronny Köpsel:
Kann mir jemand erklären, warum seit dem Update auf die 5.3 die Paketlisten mit Zahlen und Doppelpunkete übersäht sind. Zum anschauen macht einfach Pirut auf und geht auf Liste -> Alle Pakete und scrollt mal nach unten. Bsp. 1:combat-glibc-headers-2.3-4-2.26.i386
Dies ist kein Pirut Problem, da bei der Installation dies auch schon so ist. Ich habe echt schon viele Dateien durch gesehen, konnte aber bis jetzt nichts finden. Dieses Problem haben alle Redhat Ableger. Ich kann noch nicht einmal ein Bugreport schreiben, da ich nicht den Teil kenne, der dafür verantwortlich ist.
Ich würde gerne diesen Pfusch beseitigen.
Das ist das RPM Feld "Epoch". Siehe: http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html. Wenn epoch nicht 0 ist wird es angezeigt. In yum sieht das dann so aus:
compat-glibc-headers.x86_64 1:2.3.4-2.26 base
Es handelt sich hier um Pirut bug das epoch vor dem Namen und nicht vor der Version gezeigt wird.
P.S.: comBat-glibc-headers hätte ich auch gerne ;)
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Einverstanden - richtig, aber wenn ich das System neu aufsetzte, besteht das Problem doch auch schon! Oder werden Teile von Pirut bereits beim Installieren genutzt? Den "epoch" Trödel hatte ich auch schon im Verdacht, da wie du selber sagst, dass Ding dann auf 1 steht. Warum ist das eigendlich so? Ein Paket mit dem höchsten Epoch-Tag soll doch egal welche Version oder Release installiert werden. Richtig? Ist das überhaupt notwendig? Durch das Update auf die höhere Versionsnummer des zu aktualisierenden Programms ist doch der Weg bereits festgelegt. Übersehe ich etwas?
P.S.: comBat-glibc-headers hätte ich auch gerne <- jau der war gut :-X
Ronny
Am Samstag, den 11.07.2009, 21:44 +0200 schrieb Ronny Köpsel:
Christoph Maser schrieb:
Am Samstag, den 11.07.2009, 20:24 +0200 schrieb Ronny Köpsel:
Kann mir jemand erklären, warum seit dem Update auf die 5.3 die Paketlisten mit Zahlen und Doppelpunkete übersäht sind. Zum anschauen macht einfach Pirut auf und geht auf Liste -> Alle Pakete und scrollt mal nach unten. Bsp. 1:combat-glibc-headers-2.3-4-2.26.i386
Dies ist kein Pirut Problem, da bei der Installation dies auch schon so ist. Ich habe echt schon viele Dateien durch gesehen, konnte aber bis jetzt nichts finden. Dieses Problem haben alle Redhat Ableger. Ich kann noch nicht einmal ein Bugreport schreiben, da ich nicht den Teil kenne, der dafür verantwortlich ist.
Ich würde gerne diesen Pfusch beseitigen.
Das ist das RPM Feld "Epoch". Siehe: http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html. Wenn epoch nicht 0 ist wird es angezeigt. In yum sieht das dann so aus:
compat-glibc-headers.x86_64 1:2.3.4-2.26 base
Es handelt sich hier um Pirut bug das epoch vor dem Namen und nicht vor der Version gezeigt wird.
Einverstanden - richtig, aber wenn ich das System neu aufsetzte, besteht das Problem doch auch schon! Oder werden Teile von Pirut bereits beim Installieren genutzt?
Davon würde ich mal ausgehen, wieso sollten man 2 verschiedene Programme verwenden?
Den "epoch" Trödel hatte ich auch schon im Verdacht, da wie du selber sagst, dass Ding dann auf 1 steht. Warum ist das eigendlich so? Ein Paket mit dem höchsten Epoch-Tag soll doch egal welche Version oder Release installiert werden. Richtig? Ist das überhaupt notwendig? Durch das Update auf die höhere Versionsnummer des zu aktualisierenden Programms ist doch der Weg bereits festgelegt. Übersehe ich etwas?
Also ich kann Dir beim besten Willen nicht sagen warum die Paketversionen so sind wie sie sind. Aber das ganze hat nichts mit Pfusch oder Trödel zu tun. Es gibt mit Sicherheit gute Gründe für die Fälle in denen Epoch verwendet wird. Wenn das ganz für dich so wichtig ist kannst Du folgendes unternehmnen:
- Bugs einstellen (bugs.centos.org, bugzilla.redhat.com) - Ein anderes Programm nutzen (z.b. yumex) - Ein eigenes pirut packet mit einem Patch für diesen Bug basteln.
Wenn Du den ersten Weg gehen willst mach Dich daruf gefasst, dass es lange dauert. Ich würde mal schätzen ein solcher Bugfix würde für 5.5 oder 5.6 geplant werden.
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Ronny Köpsel schrieb:
Warum ist das eigendlich so? Ein Paket mit dem höchsten Epoch-Tag soll doch egal welche Version oder Release installiert werden. Richtig? Ist das überhaupt notwendig? Durch das Update auf die höhere Versionsnummer des zu aktualisierenden Programms ist doch der Weg bereits festgelegt. Übersehe ich etwas?
Der Epoch-Tag ist eine Notlösung, falls der Packager einen Fehler gemacht hat oder ein bereits veröffentlichtes Paket wieder zurückgezogen werden muss. Anschließend muss der alte Epoch-Wert für alle Ewigkeiten mitgeführt werden, wenn man den Upgrade-Pfad nicht mutwillig kaputt machen will.
fs
Felix Schwarz schrieb:
Ronny Köpsel schrieb:
Warum ist das eigendlich so? Ein Paket mit dem höchsten Epoch-Tag soll doch egal welche Version oder Release installiert werden. Richtig? Ist das überhaupt notwendig? Durch das Update auf die höhere Versionsnummer des zu aktualisierenden Programms ist doch der Weg bereits festgelegt. Übersehe ich etwas?
Der Epoch-Tag ist eine Notlösung, falls der Packager einen Fehler gemacht hat oder ein bereits veröffentlichtes Paket wieder zurückgezogen werden muss. Anschließend muss der alte Epoch-Wert für alle Ewigkeiten mitgeführt werden, wenn man den Upgrade-Pfad nicht mutwillig kaputt machen will.
fs
Danke, genau so eine Antwort habe ich gebraucht. Ich will es ja auch verstehen. Es nützt mir nichts, wenn ich Dinge so hinnehme wie sie sind.
Ronny
-
Christoph Maser -
Felix Schwarz -
Ronny Köpsel