Besonderheiten bei Architektur von all zu any?[gelöst]

[nudgegoonies]

Ein Ruby-Paket, welches bisher aufgrund seiner architekturunabhängigkeit auf 'all' stand, habe ich nun auf 'any' gewechselt, da Gems dies erfordern. Gibt es noxh etwas zu beachten? Ich habe ein Update in einer VM durchgespielt und mir ist so erstmal nichts aufgefallen. Lintian clean ist es nicht, weil jetzt architekturabhängige Dateien in /usr/share sind. Soviel weiß ich schon.

[Natureshadow]

Häh? Ist es architekturabhängig oder nicht? Wenn nicht, ist es Architektur all, egal was irgendein Gems-System meint...

Wenn das nicht geht, ist Gems kaputt.

-nik

[nudgegoonies]

Es ist eben architekturabhängig. Im Paket selbst sind Gems enthalten, die beim Bau des Paketes mit architekturabhängigen Libraries gelinkt werden. Darum ist 'all' eben falsch. Natürlich wäre es erst dann richtig und gut wenn alle Gems in eigenen Paketen ausgelagert wären, aber so ist der Status quo leider noch nicht. Darum will ich verhindern dass es auf i386 Probleme gibt, wenn das Paket unter amd64 gebaut wurde. Eine Alternative wäre, es 'all' zu lassen, sämtliche für den Bau der Gems nötigen Headers nicht mehr nur als 'build-depends' zu setzen sondern auch für die fertigen Pakete und die Gems während der Installation zu bauen. Der Umbau ist mir aber gerade zu groß.

[Natureshadow]

Es ist eben architekturabhängig. Im Paket selbst sind Gems enthalten, die beim Bau des Paketes mit architekturabhängigen Libraries gelinkt werden. Darum ist 'all' eben falsch. Natürlich wäre es erst dann richtig und gut wenn alle Gems in eigenen Paketen ausgelagert wären, aber so ist der Status quo leider noch nicht. Darum will ich verhindern dass es auf i386 Probleme gibt, wenn das Paket unter amd64 gebaut wurde. Eine Alternative wäre, es 'all' zu lassen, sämtliche für den Bau der Gems nötigen Headers nicht mehr nur als 'build-depends' zu setzen sondern auch für die fertigen Pakete und die Gems während der Installation zu bauen. Der Umbau ist mir aber gerade zu groß.

In jedem Fall solltest du dich damit an pkg-ruby-dev@lists.aioth.debian.org wenden.

-nik

[KBDCALLS]

Ich habe jedenfalls noch kein any.deb gesehen. any ist doch nur ein Platzhalter, damit man für alle Architekturen Pakete bauen kann, bzw. nicht alle einzeln auführen muß in der controldatei der Sourcen.

Am BeIspiel von Paket vlc-data . Das ist Architekturabhängig , also überall gleich

Code: Alles auswählen

Package: vlc-data
Depends: ${misc:Depends}
Architecture: all

Das Paket vlc-plugin-svgalib gibts nur die Architekturen amd64 und i386

Code: Alles auswählen

Package: vlc-plugin-svgalib
Architecture: amd64 i386

Und das Paket vlc-plugin-zvbi für any
auf Deutsch für alle

Code: Alles auswählen

Package: vlc-plugin-zvbi
Architecture: any

Das könnte auch so ausehen.

Code: Alles auswählen

Package: vlc-plugin-zvbi
Architecture: amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mipsel powerpc s390 s390x sparc

Das any dient also nur dazu die Architekture Zeile abzukürzen.

[hikaru]

Und das Paket vlc-plugin-zvbi für any
auf Deutsch für alle

Krümelkackermodus an:
Streng genommen heißt any nicht alle sondern jede.

Der Unterschied ist folgender:
Wir sind hundert Leute und feiern eine Party.
A: Im Garten steht ein wirklich großer Swimmingpool. Den können alle benutzen - gleichzeitig.
B: Im Garten steht ein kleines Planschbecken. Das kann jeder benutzen - aber nicht alle gleichzeitig.

So wie ich das hier aus dem Thread entnehme (eigene Erfahrungen fehlen mir) verhält es sich wohl ähnlich mit den Paketen, je nachdem ob die Abhängigkeiten architekturspezifisch sind.

[nudgegoonies]

In jedem Fall solltest du dich damit an pkg-ruby-dev@lists.aioth.debian.org wenden.

Danke für den Tip. Laut der Entwickler ist der korrekte Weg die Gems einzeln zu paketieren. Es landet alles in /usr/lib/ruby/vendor_ruby/(name) und wenn architekturabhängige *.so's dabei sind in /usr/lib/ruby/vendor_ruby/1.X/x86_64-linux etc. Aber wie gesagt, alle Gems einzeln paketieren ist erstmal nicht geplant.

Ich habe jedenfalls noch kein any.deb gesehen. any ist doch nur ein Platzhalter, damit man für alle Architekturen Pakete bauen kann, bzw. nicht alle einzeln auführen muß in der controldatei der Sourcen.

Genauso habe ich es auch verstanden und darum die Architektur auf any gesetzt. Hinten raus kommt amd64, i386, etc. je nach Buildumgebung.

Ich habe so langsam das Gefühl, ich habe mich missverständlich ausgedrückt. Es geht mir um die Aktualisierung eines Paketes, das mit der Architektur all installiert ist und wo nun das aktualisierte Paket die Architektur amd64 hat.

P.S.
Habe den Thread auf gelöst gesetzt. So rein aus der Praxis heraus würde ich sagen, es ist kein Problem ein Paket zu aktualisieren, dessen installierte Architektur all war und dessen neue Architektur spezifisch ist (in meinem Fall amd64).