# (gelöst)Portage fehlerhaft bei/mit Openoffice(Design-Fehler)

## UTgamer

Ich habe heute nach mehreren Tagen mal wieder gesynct und das neue Portage 2.1.6.4 verhält sich fehlerhaft was "emerge world" angeht.

Also ich habe Openoffice 3.0 vor längerer Zeit installiert und emerge will es einfach von sich aus bei world auf nicht vorhanden Bibliotheken re-mergen.

 *Quote:*   

> app-office/openoffice
> 
>        Latest version available: 3.0.0
> 
>        Latest version installed: 3.0.0
> ...

 

Dies ist meine emerge world Ausgabe:

 *Quote:*   

>  emerge world -pv
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done!
> ...

 

Ich glaube das neue Portage ist ganz schön fehlerhaft, denn ich will garnicht das sauber laufende Openoffice remergen.   :Evil or Very Mad: 

Die vorherigen Openoffice Pakete 2.4 hatten ebenfalls häufiger den gleichen Bug:

https://forums.gentoo.org/viewtopic-t-550988-highlight-devperl+compressrawzlib.html

https://bugs.gentoo.org/show_bug.cgi?id=219095

Habt ihr eine Lösung damit ich emerge weiter verwenden kann; soll ich vielleicht Portage downgraden bis die neueren Versionen wieder fehlerfrei sind?

Also Portage kann die Neukompilierung auf die nicht existierende >=dev-perl/Compress-Raw-Zlib-2.002 nicht machen, denn richtig ist diese Bibliothek: perl-core/Compress-Raw-Zlib-2.015.

----------

## Polynomial-C

```
emerge world
```

 macht seit portage-2.1.6 genau das, was es soll, nämlich alle Pakete aus dem world set neu zu installieren. Schau mal, ob 

```
emerge -u world
```

 hilft. Das Thema ist auch bereits hier vertreten.

----------

## UTgamer

Danke, damit komme ich erstmal weiter bis der Bug behoben ist.

(Bug ist es immer solange wie etwas unerwartetes nicht dokumentiert ist.)

Ich hatte zuerst "emerge system" ohne "-u" durchgeführt und das lief sauber durch.

Soll das jetzt heissen das "emerge world" anders als "emerge system" in Zukunft nur noch mit -u funktioniert? Obwohl da fällt mit ein das mein "emerge system" noch mit dem alten Portage lief.

 *Quote:*   

> emerge -u world -pv
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done!
> ...

 Ich frage mich nur wo einmal diese nicht vorhandene Perl-lib herkommt, vorher hatte Openoffice ja auch sauber ohne diese Lib kompiliert.

----------

## UTgamer

Ich habe den Perlfehler ausgemacht, und auch ein echter Bug.

Die Devs haben app-office/openoffice-3.0.0 einfach augetaucht ohne die Versionsnummer zu ändern. Für alle die ein lokales Overlay nutzen eine Unmöglichkeit bezüglich der Devs.

Den das Originalpaket prüft auf die ~5GB Tempgröße mit fehlerhaften Scripten die ich auch bereits gemeldet habe aber die wohl seit Jahren nicht gefixt werden. Der Fehler ist das man nach /var/tmp/portage nicht mounten darf wenn das Tempgrößenabfragescript auf die Grösse überprüft. Es bleibt einem garnichts anderes über wenn die /var Partiton zu klein partitioniert hat oder einfach von vornherein eine eigenen Partition für /var/tmp/portage eingeplant hatte.

Also Ignorierung von jahrealten Bugs und die die auf das Overlay angewiesen sind vor den Kopf zu stoßen. Richtig währe es gewesen die Versionsnummer zu ändern. z.B. auf: -3.0.0.1.

Bleibt mir jetzt nichts anderes über als erneut zu digest-en.    :Sad:  Die Fehlersuche währe nicht nötig gewesen und dann auch erst recht nicht zeitgleich in Verbindung mit unangekündigten Portageänderungen. Datum des neuen openoffice-ebuilds mit gleicher Versionsnummer ist der 28.12.2008. *grrrr*

Alte 3.0.0

 *Quote:*   

> DEPEND="${COMMON_DEPEND}
> 
> 	x11-libs/libXrender
> 
> 	x11-libs/libXtst
> ...

 

Neue 3.0.0

 *Quote:*   

> DEPEND="${COMMON_DEPEND}
> 
> 	x11-libs/libXrender
> 
> 	x11-libs/libXtst
> ...

 

----------

## mv

 *UTgamer wrote:*   

> Die Devs haben app-office/openoffice-3.0.0 einfach augetaucht ohne die Versionsnummer zu ändern. Für alle die ein lokales Overlay nutzen eine Unmöglichkeit bezüglich der Devs.

 

Nein, sondern vollkommen korrektes und sinnvolles Verhalten: Es wäre eine Zumutung, wenn man wegen einer Umbenennung eines anderen Pakets openoffice neu kompilieren müsste.

Das Grundproblem ist vielmehr, dass das Konzept, zum Patchen eines Ebuilds das gesamte Ebuild kopieren zu müssen, "broken-by-design" ist. Für einfache Patches beim Bauen kann man sich glücklicherweise inzwischen mit /etc/portage/env/* behelfen, aber mein Vorschlag, Ähnliches auch für die Meta-Daten zu erlauben, wurde leider abgelehnt.

----------

## UTgamer

 *mv wrote:*   

> ...
> 
> Das Grundproblem ist vielmehr, dass das Konzept, zum Patchen eines Ebuilds das gesamte Ebuild kopieren zu müssen, "broken-by-design" ist. Für einfache Patches beim Bauen kann man sich glücklicherweise inzwischen mit /etc/portage/env/* behelfen, aber mein Vorschlag, Ähnliches auch für die Meta-Daten zu erlauben, wurde leider abgelehnt.

 

Man hätte irgendwie darauf hinweisen sollen und wenn es wenigstens mit dem Portage-Update gemeldet worden währe, dort ist ja nichtmal die Benutzungsänderung mitgeteilt worden, welches für Personen die gleichzeitig auf Fehler treffen einiges erklärt hätte. :/

Ja stimmt im Design müßte noch einiges abgeändert werden.

----------

## Polynomial-C

Ich habe mir hier einen Alias erstellt, mit dem ich regelmäßig nach Unterschieden zwischen den ebuilds aus meinem Overlay und denen aus dem Portage-tree schaue: 

```
alias compare-trees='for pkg in $(find /usr/local/portage -type f -name "*.ebuild") ; do test -f "${pkg/\/local}" && colordiff -u "${pkg}" "${pkg/\/local}" | less ; done'
```

Falls du colordiff nicht magst, dann ändere das einfach in diff um und dein Overlay sollte in /usr/local/portage liegen oder du schreibst den alias halt so um, daß es mit deinem Overly paßt.   :Smile: 

----------

## UTgamer

Super Polynomial-C, das Alias übernehme ich direkt auch mal.  :Smile: 

Ich finde es klasse wie so Systeme langsam aber stetig den eigenen Wünschen entsprechend wachsen, das geht eben auch nur mit Source basierenden Distros wie Gentoo.

----------

