# Gentoo docutils 0.18 update Fehler

## alexander_ro

Hallo

wie man unten sehen kann habe wird docutils-0.18.1:0 nicht installiert weil er irgengwiee an der 0.17 hängt. Ich habe mal versucht die drei Pakete 

docutils-0.18.1:0

sphinx-4.4.0:0

sphinx_rtd_theme-1.0.0:0

zu entfernen und dann neu zu installieren. Das ändert aber nichts er weigert sich weiter das zu installieren. Eintragen der docutils 17 in die package.mask hat auch nichts verbessert.

Was er mir damit sagen will ist mir auch nicht ganz klar: (no parents that aren't satisfied by other packages in this slot)

Vielleicht hat ja jemand einen Tipp wie ich das reparieren kann.

Viele Grüße

Alexander

```

emerge --ask --verbose-conflicts --update --deep --with-bdeps=y --newuse @world

 * IMPORTANT: 7 news items need reading for repository 'gentoo'.

 * Use eselect news read to view new items.

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! Multiple package instances within a single package slot have been pulled

!!! into the dependency graph, resulting in a slot conflict:

dev-python/docutils:0

  (dev-python/docutils-0.18.1:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)" PYTHON_TARGETS="python3_9 (-pypy3) -python3_10 -python3_8" pulled in by

    (no parents that aren't satisfied by other packages in this slot)

  (dev-python/docutils-0.17.1:0/0::gentoo, installed) USE="" ABI_X86="(64)" PYTHON_TARGETS="python3_9 (-pypy3) -python3_10 -python3_8" pulled in by

    <dev-python/docutils-0.18[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/sphinx-4.4.0:0/0::gentoo, installed) USE="-doc -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_9 (-pypy3) -python3_10 -python3_8"

    ^                    ^^^^                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

    <dev-python/docutils-0.18[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/sphinx_rtd_theme-1.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_9 (-pypy3) -python3_10 -python3_8"

    ^                    ^^^^                                                                                                                                                                                                                                                                                                                                                                                                                                                        

It may be possible to solve this problem by using package.mask to

prevent one of those packages from being selected. However, it is also

possible that conflicting dependencies exist such that they are

impossible to satisfy simultaneously.  If such a conflict exists in

the dependencies of two different packages, then those packages can

not be installed simultaneously. You may want to try a larger value of

the --backtrack option, such as --backtrack=30, in order to see if

that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man

page or refer to the Gentoo Handbook.

The following packages are causing rebuilds:

  (dev-libs/icu-70.1-r1:0/70.1::gentoo, ebuild scheduled for merge) causes rebuilds for:

    (dev-lang/spidermonkey-78.15.0:78/78::gentoo, ebuild scheduled for merge)

    (media-libs/libvisio-0.1.7:0/0::gentoo, ebuild scheduled for merge)

    (dev-qt/qtcore-5.15.2-r14:5/5.15.2::gentoo, ebuild scheduled for merge)

    (media-libs/harfbuzz-3.2.0:0/3.0.0::gentoo, ebuild scheduled for merge)

    (dev-libs/libical-3.0.12:0/3::gentoo, ebuild scheduled for merge)

    (dev-db/sqlite-3.37.2:3/3::gentoo, ebuild scheduled for merge)

    (media-libs/libcdr-0.1.7:0/0::gentoo, ebuild scheduled for merge)

    (app-text/libmspub-0.1.4:0/0::gentoo, ebuild scheduled for merge)

    (dev-libs/boost-1.78.0-r2:0/1.78.0::gentoo, ebuild scheduled for merge)

    (dev-qt/qtwebengine-5.15.2_p20211216:5/5.15::gentoo, ebuild scheduled for merge)

    (media-libs/raptor-2.0.15-r4:2/2::gentoo, ebuild scheduled for merge)

    (net-libs/webkit-gtk-2.34.6:4/37::gentoo, ebuild scheduled for merge)

    (app-text/libebook-0.1.3-r2:0/0::gentoo, ebuild scheduled for merge)

    (app-text/libqxp-0.0.2:0/0::gentoo, ebuild scheduled for merge)

    (app-office/libreoffice-7.2.5.2-r1:0/0::gentoo, ebuild scheduled for merge)

    (net-libs/nodejs-14.17.6:0/14::gentoo, ebuild scheduled for merge)

    (x11-libs/vte-0.64.2:2.91/2.91::gentoo, ebuild scheduled for merge)

    (media-libs/libzmf-0.0.2:0/0::gentoo, ebuild scheduled for merge)

    (dev-db/postgresql-13.5:13/13::gentoo, ebuild scheduled for merge)

    (dev-libs/re2-0.2021.11.01:0/9::gentoo, ebuild scheduled for merge)

  (media-libs/opencv-4.5.5-r1:0/4.5.5::gentoo, ebuild scheduled for merge) causes rebuilds for:

    (media-libs/libopenshot-0.2.7:0/21::gentoo, ebuild scheduled for merge)

!!! All ebuilds that could satisfy "sys-devel/llvm:13" have been masked.

!!! One of the following masked packages is required to complete your request:

- sys-devel/llvm-13.0.1::gentoo (masked by: package.mask, ~amd64 keyword)

- sys-devel/llvm-13.0.0::gentoo (masked by: package.mask)

(dependency required by "dev-lang/spidermonkey-78.15.0::gentoo" [ebuild])

(dependency required by "sys-auth/polkit-0.120-r3::gentoo" [ebuild])

(dependency required by "gnome-extra/polkit-gnome-0.105-r2::gentoo" [installed])

For more information, see the MASKED PACKAGES section in the emerge

man page or refer to the Gentoo Handbook.

```

----------

## mike155

Fangen wir erst mal hinten an.

Ich nehme an, dass Du kürzlich "emerge --sync" durchgeführt hast - also auf dem aktuellen Stand bist?

Was bedeutet diese Meldung:

```
!!! All ebuilds that could satisfy "sys-devel/llvm:13" have been masked.

!!! One of the following masked packages is required to complete your request:

- sys-devel/llvm-13.0.1::gentoo (masked by: package.mask, ~amd64 keyword)

- sys-devel/llvm-13.0.0::gentoo (masked by: package.mask)

```

Hast Du llvm in die package.mask aufgenommen? Warum?

----------

## alexander_ro

Ja emerge --sync hatte ich gestern gemacht. Auf Deine Frage gerade nochmal gemacht ändert sich aber nichts ... einen Versuch war es Wert.

Nein habe ich nicht in der package.mask aber in der make.conf ein -llvm weil ich es nicht haben möchte.

----------

## firefly

das mit dem docutils ist kein bug in dem sinne

dev-python/sphinx_rtd_theme-1.0.0 hat keinen support für docutils >= 0.18

https://bugs.gentoo.org/802618

EDIT: Und bevor jemand meint auf einmal docutils in package.mask zu packen oder systemweit das doc useflag zu deaktivieren bitte diesen post im bugreport lesen und verstehen:

https://bugs.gentoo.org/802618#c16

----------

## firefly

 *alexander_ro wrote:*   

> Nein habe ich nicht in der package.mask aber in der make.conf ein -llvm weil ich es nicht haben möchte.

 

Das stimmt leider nicht. Denn llvm:13 ist in portage als stable markiert.

Daher kann es nur sein dass du irgendwann llvm in package.mask eingetragen hast

----------

## alexander_ro

Wenn man meine Frage oben liest wo steht da das ich irgendwas zu llvm wissen will?

Ich würde das nur wissen wollen wenn es einen Zusammenhang mit den docutils Problem gibt.

Was soll man dann tun um das mit dem docutils zu beheben. Wenn es keine passende Version gibt warum will es dann bei automatischen Updates installiert werden. Die letzte funktionsfähige Stabile Version ist ja dann die 17 mit der ist es aber nicht zufrieden. Verstehe ich jetzt nicht.

----------

## pietinger

 *alexander_ro wrote:*   

> Wenn man meine Frage oben liest wo steht da das ich irgendwas zu llvm wissen will?

 

Deine Ausgangsfrage im ersten Post war doch: "Vielleicht hat ja jemand einen Tipp wie ich das reparieren kann."

@mike155 und @firefly haben danach freundlich versucht Dir zu erklären, dass momentan nichts gegen die WARNUNG bezüglich docutils und sphinx_rtd_theme getan werden kann (und/oder müsste), außer Du möchtest solch drakonische Maßnahmen wie im verlinkten Bugreport beschrieben, durchführen (-doc).

DAS führt also nicht zu einem ABBRUCH eines world-updates.

Etwas anderes schon, nämlich LLVM. Davon möchtest Du aber nichts wissen. Das ist natürlich Deine Entscheidung. Aber wenn Du wirklich wieder mal ein "emerge -uvDU @world" machen möchtest, dann solltest Du vielleicht einige Packages vorher rausschmeißen ... oder Du entfernst das "-llvm" aus Deiner make.conf ... DENN: icu bewirkt einen rebuild von spidermonkey, welches halt leider den llvm benötigt. Welche Pakete Du rausschmeißen mußt um am "-llvm" festhalten zu können, weißt Du sicherlich.Last edited by pietinger on Wed Mar 09, 2022 9:17 pm; edited 2 times in total

----------

## mike155

Der obige Emerge-Fehlerbericht zeigt zwei Probleme:

Ein Problem mit docutils

Ein Problem mit llvm

Ich habe Dir etwas zu dem zweiten Problem geschrieben. Das wirst Du auch lösen müssen - auch wenn Du nicht danach gefragt hast. 

Tatsächlich mache ich es im Falle längerer Emerge-Fehlermeldungen so, dass ich mit den einfachen und offensichtlichen Fehlern anfange. In diesem Fall ist es das LLVM-Problem. Zum einen werden die Emerge-Fehlerberichte dadurch schnell kürzer - und zum anderen lösen sich die komplizierten Probleme dadurch manchmal von selbst.

----------

## alexander_ro

Ich habe nur freundlich gesagt das ich das nicht brauche muss ich mir erst selbst noch überlegen was ich da mache.

Das man nichts gegen die Meldung zu docutils tun kann konnte ich jetzt nicht wirklich da herauslese, Vielleicht irgendwas in dem Bugreport falsch übersetzt. Ok dann weiß ich das jetzt und setze es erstmal in die package.mask das bekomme ich ja wieder gemeldet wenn es dann mit der 17 nicht mehr geht.

Danke für die Infos ...  :Smile: 

Edit:

Doch noch eine Frage zu llvm den braucht man unter ARM nicht ist das richtig?

Der sagt ja wenn ich icu 70 installieren will muss er postgresql neu bauen.

Von meinem ARM System (ohne llvm):

```

qlist -Iv | grep icu

dev-libs/icu-70.1-r1

qlist -Iv | grep postgresql

app-eselect/eselect-postgresql-2.4

dev-db/postgresql-13.5

```

----------

## Josef.95

 *alexander_ro wrote:*   

> 
> 
> ```
> !!! All ebuilds that could satisfy "sys-devel/llvm:13" have been masked.
> 
> ...

 

Hi,

sys-auth/polkit-0.120-r3 braucht dev-lang/spidermonkey:78, welches zum bauen sys-devel/llvm braucht.

Als Workaround könnte man das neue sys-auth/polkit-0.120_p20220221 mit USE=duktape testen (ja, ist aktuell noch testing),

damit sollte es dann mit dev-lang/duktape statt spidermonkey, und ohne sys-devel/llvm gehen.

----------

## mike155

Es hängt immer davon ab, was man machen will. 

Da mir Sicherheit wichtig ist, deaktiviere ich nach Möglichkeit pam und polkit.

Dort wo ich pam doch brauche, deaktiviere ich polkit über /etc/portage/profile/package.provided:

```
sys-auth/polkit-0.115-r4

sys-fs/udisks-2.8.2

sys-auth/polkit-qt-0.112.0_p20160416-r2

kde-plasma/polkit-kde-agent-5.16.5

kde-frameworks/kactivities-5.60.0

xfce-extra/thunar-volman-4.16

x11-misc/xdg-user-dirs-0.17
```

Es gibt aber Systemumgebungen, bei denen man pam und/oder polkit braucht. Dann kann man natürlich nicht so vorgehen.

Das Use-Flag "doc" ist bei mir auf allen Maschinen systemweit deaktiviert. Für einzelne Pakete, bei denen ich die Doku haben möchte, aktiviere ich das "doc" USE-Flag über package.use. 

Gründe für das systemweite Deaktivieren des "doc" USE-Flags sind:

Zum Bauen der Dokumentation sind weitere Pakete wie doxygen, graphviz oder TeX notwendig, die ich nicht auf meinem Systemen installiert haben möchte.

Es gab immer mal wieder Probleme beim Bauen der Dokumentation. Gerade Sphinx hat da eine lange Tradition.

Es gab zumindest früher ein paar Pakete, bei denen das Bauen der Doku (zu) lange gedauert hat.

Ich lese die Doku meistens doch online auf der Website der Projekte. Ich benötige sie gar nicht auf meinen Rechnern.

----------

## alexander_ro

Ich habe mal polkit einfach installiert. Das hat funktioniert wenn ich es manuell mache.

```

qlist -Iv | grep polkit

acct-group/polkitd-0-r1

acct-user/polkitd-0-r1

gnome-extra/polkit-gnome-0.105-r2

sys-auth/polkit-0.120-r3

```

Jetzt sieht es etwas anders aus:

```

emerge --ask --update --deep --with-bdeps=y --newuse @world

 * IMPORTANT: 7 news items need reading for repository 'gentoo'.

 * Use eselect news read to view new items.

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following packages are causing rebuilds:

  (dev-libs/icu-70.1-r1:0/70.1::gentoo, ebuild scheduled for merge) causes rebuilds for:

    (dev-libs/boost-1.78.0-r2:0/1.78.0::gentoo, ebuild scheduled for merge)

    (app-text/libqxp-0.0.2:0/0::gentoo, ebuild scheduled for merge)

    (dev-db/sqlite-3.37.2:3/3::gentoo, ebuild scheduled for merge)

    (dev-libs/re2-0.2021.11.01:0/9::gentoo, ebuild scheduled for merge)

    (dev-libs/libical-3.0.12:0/3::gentoo, ebuild scheduled for merge)

    (net-libs/webkit-gtk-2.34.6:4/37::gentoo, ebuild scheduled for merge)

    (app-text/libmspub-0.1.4:0/0::gentoo, ebuild scheduled for merge)

    (dev-lang/spidermonkey-78.15.0:78/78::gentoo, ebuild scheduled for merge)

    (media-libs/libvisio-0.1.7:0/0::gentoo, ebuild scheduled for merge)

    (net-libs/nodejs-14.17.6:0/14::gentoo, ebuild scheduled for merge)

    (dev-qt/qtcore-5.15.2-r14:5/5.15.2::gentoo, ebuild scheduled for merge)

    (media-libs/libzmf-0.0.2:0/0::gentoo, ebuild scheduled for merge)

    (dev-db/postgresql-13.5:13/13::gentoo, ebuild scheduled for merge)

    (app-office/libreoffice-7.2.5.2-r1:0/0::gentoo, ebuild scheduled for merge)

    (media-libs/harfbuzz-3.2.0:0/3.0.0::gentoo, ebuild scheduled for merge)

    (app-text/libebook-0.1.3-r2:0/0::gentoo, ebuild scheduled for merge)

    (media-libs/libcdr-0.1.7:0/0::gentoo, ebuild scheduled for merge)

    (dev-qt/qtwebengine-5.15.2_p20211216:5/5.15::gentoo, ebuild scheduled for merge)

    (media-libs/raptor-2.0.15-r4:2/2::gentoo, ebuild scheduled for merge)

  (media-libs/opencv-4.5.5-r1:0/4.5.5::gentoo, ebuild scheduled for merge) causes rebuilds for:

    (media-libs/libopenshot-0.2.7:0/21::gentoo, ebuild scheduled for merge)

!!! All ebuilds that could satisfy "sys-devel/llvm:13" have been masked.

!!! One of the following masked packages is required to complete your request:

- sys-devel/llvm-13.0.1::gentoo (masked by: package.mask)

- sys-devel/llvm-13.0.0::gentoo (masked by: package.mask)

(dependency required by "dev-lang/spidermonkey-78.15.0::gentoo" [ebuild])

(dependency required by "@__auto_slot_operator_replace_installed__" [argument])

For more information, see the MASKED PACKAGES section in the emerge

man page or refer to the Gentoo Handbook.

```

----------

## ManfredB

Hallo Josef.95!

Ich habe das eben auch einmal getestet:

emerge --ask "=sys-auth/polkit-0.120_p20220221"

Es wurden 2 Pakete installiert:

[ebuild  N     ] dev-lang/duktape-2.6.0 

[ebuild     U ~] sys-auth/polkit-0.120_p20220221 [0.120-r3] USE="duktape%*"

Danach habe ich emerge --ask --depclean eingegeben:

```

>>> These are the packages that would be unmerged:

 dev-lang/spidermonkey

    selected: 78.15.0 

   protected: none 

     omitted: none 

 sys-devel/autoconf

    selected: 2.13-r1 

   protected: none 

     omitted: 2.71-r1 

 sys-devel/llvmgold

    selected: 13-r1 

   protected: none 

     omitted: none 

 sys-devel/llvm

    selected: 13.0.1 

   protected: none 

     omitted: none 

 sys-devel/llvm-common

    selected: 13.0.1 

   protected: none 

     omitted: none 

All selected packages: =sys-devel/llvm-common-13.0.1 =sys-devel/llvmgold-13-r1 =sys-devel/llvm-13.0.1 =sys-devel/autoconf-2.13-r1 =dev-lang/spidermonkey-78.15.0

```

Wohlgemerkt: es ist nur ein Test, um herauszufinden, ob llvm tatsächlich nicht mehr gebraucht wird.

Gruß

Manfred

P.S. diese Meldung bezieht sich auf gentoo-stable.

In gentoo-unstable ist es schon installiert.

----------

## Josef.95

Hallo ManfredB!

ja, das war der Plan - danke fürs testen :)

Eventuell mag alexander_ro den Vorschlag ja auch mal testen :)

----------

## alexander_ro

Ich habe den Vorschlag schon gelesen danke dafür weil ich duktape auch noch nicht kannte klingt interessant,. Sorry wenn ich nicht alles einfach nachmache. Ich wollte mit dem aktuellen Zustand noch ein bisschen Experimentieren. Aber danke das es schon jemand ausprobiert hat und Beschrieben. Ich habe noch alles ausprobiert was mir hier vorgeschlagen wurde. Es sei den es war klar das ich das so nicht möchte. Dein Vorschlag geht ja genau in die Richtung die ich möchte.

Ich frage mich gerade nur wie kam spidermonkey in dieser aktuellen Version auf den Rechner. Das ohne llvm habe ich schon sehr lange. Fragen über Fragen ...

...

Jetzt habe ich das mal probiert:

Stimmt er entfernt dann den spidermonkey.

Ob das gut ist?

```

equery depends spidermonkey

 * These packages depend on spidermonkey:

net-libs/libproxy-0.4.17 (spidermonkey ? dev-lang/spidermonkey:68)

sys-auth/polkit-0.120_p20220221 (!duktape ? dev-lang/spidermonkey:91[-debug])

```

```

qlist -Iv | grep libproxy

net-libs/libproxy-0.4.17

```

----------

## Josef.95

 *alexander_ro wrote:*   

> Ob das gut ist?

 

Puh, ob es gut ist die von polkit benötigte Javascript engine von spidermonkey gegen die von duktape auszutauschen, kann ich nicht beurteilen.

duktape wird von polkit upstream in der neuen Version nun offiziell unterstützt, von daher sollte es ok sein.

Ich wollte mit dem Vorschlag nur eine Alternative aufzeigen, wie man mit deiner (warum auch immer) hart maskierten sys-devel/llvm Abhängigkeit wieder einen sauberen dep tree hinbekommen könnte.

----------

## alexander_ro

Das Meinte ich gar nicht. Sondern das der den Spidermonkey entfernt hat.

Mir zeigt der an das die libproxy den auch braucht.

----------

## mike155

Nur wenn Du libproxy mit USE-Flag "spidermonkey" installiert hast. Hast Du?

```
# equery d spidermonkey

 * These packages depend on spidermonkey:

net-libs/libproxy-0.4.17 (spidermonkey ? dev-lang/spidermonkey:68)
```

----------

## alexander_ro

Also ich habe nichts mit spidermonkey gesetzt. Er zeigt es halt an bei: equery depends spidermonkey

Dann war es also richtig das er den nicht mehr braucht und entfernt hat.

----------

## mike155

Ja, "emerge --depclean" entfernt normalerweise keine Pakete, die noch gebraucht werden. Und die Ausgabe von "equery d spidermonkey" zeigt ja, dass das Paket "libproxy" das Paket "spidermonkey" nur dann benötigt, wenn das USE-Flag "spidermonkey" gesetzt ist.

"emerge --update --deep --changed-use -av @world" sollte jetzt auch nicht mehr das Paket "llvm" reinziehen wollen, richtig?

----------

## alexander_ro

Jetzt hat er alle Updates durch.

Das hat doch recht lange gedauert waren aber auch die größten Pakete mit dabei.

Bis jetzt sieht es so aus als ob alles laufen würde. Danke für eure Hilfe.

Ja ich weiß bisher hatte das emerge --depclean immer recht. Was ich ein bisschen unschön finde ist das es Kernel Sourcecode entfernt auch wenn der noch benutzt wird. Das ist aber auch nicht so schlimm weil es die .config ja übrig lässt. Muss man den halt evtl. wieder neu installieren.

Man kann das aber dem Text nicht ansehen ob es gesetzt ist oder nicht?

```

net-libs/libproxy-0.4.17 (spidermonkey ? dev-lang/spidermonkey:68)

```

Da manche dieser USE-Flag auch Standardmäßig gesetzt sind hätte es ja sein können.

Ja stimmt das llvm will er aktuell nicht mehr haben.

----------

## Christian99

 *alexander_ro wrote:*   

> 
> 
> Ja ich weiß bisher hatte das emerge --depclean immer recht. Was ich ein bisschen unschön finde ist das es Kernel Sourcecode entfernt auch wenn der noch benutzt wird. Das ist aber auch nicht so schlimm weil es die .config ja übrig lässt. Muss man den halt evtl. wieder neu installieren.
> 
> 

 

naja depclean entfernt halt alle pakete, zu denen keine abhägigkeit besteht. Der schaut nicht welcher Kernel gerade läuft. Ist mMn auch nicht sinnvoll.

du kannst ja --exclude verwenden, das geht auch bei --depclean, da kannst du dann pakete angeben die nicht gecleaned werden sollen.

 *Quote:*   

> 
> 
> Man kann das aber dem Text nicht ansehen ob es gesetzt ist oder nicht?
> 
> ```
> ...

 

eix geht dafür ganz gut:

```
eix libproxy

[I] net-libs/libproxy

     Verfügbare Versionen:   0.4.17^t {gnome kde mono networkmanager spidermonkey test webkit ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32"}

     Installierte Versionen: 0.4.17^t(03:35:02 04.01.2021)(kde networkmanager -gnome -mono -spidermonkey -test -webkit ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")

     Startseite:             https://github.com/libproxy/libproxy

     Beschreibung:           Library for automatic proxy configuration management
```

----------

## Josef.95

 *Quote:*   

> 
> 
> ```
> net-libs/libproxy-0.4.17 (spidermonkey ? dev-lang/spidermonkey:68)
> ```
> ...

 

Ist für das (selbst gemachte) llvm Problem irrelevant, da spidermonkey:68 ein anderer Slot ist, der kein llvm braucht.

----------

## alexander_ro

Das ist nicht Korrekt ich habe llvm nicht gemacht also habe ich das Problem auch nicht gemacht. Technisch gesehen ist llvm ein Irrweg aber die Ami hörige Software Entwicklung wird auch diesem Weg folgen. Wie immer ist die Idee von dem was man erreichen will vielleicht gut die Umsetzung ist aber extrem schlecht.

Ich versuche nur die Problem zu lösen die mir andere an den Hals binden ...  :Sad: 

----------

## Christian99

 *alexander_ro wrote:*   

> Das ist nicht Korrekt ich habe llvm nicht gemacht also habe ich das Problem auch nicht gemacht. Technisch gesehen ist llvm ein Irrweg aber die Ami hörige Software Entwicklung wird auch diesem Weg folgen. Wie immer ist die Idee von dem was man erreichen will vielleicht gut die Umsetzung ist aber extrem schlecht.
> 
> Ich versuche nur die Problem zu lösen die mir andere an den Hals binden ... 

 

wow, ziemlich starkes statement...

Aber ich muss dir widersprechen, in dem Punkt, dass das Problem selber gemacht ist:

Wenn du llvm unmaskierst, wird es einfach funktionieren. Wenn du unbedingt llvm nicht haben willst, dann darfst du auch Sachen, die llvm explizit benötigen nicht verwenden, und pakete die diese benötigen, usw.

Wenn dann emerge Probleme hat, weil durch die unvollständigen Maskierungen, falsche USE flags, was auch immer zu einen solchen dependency konflikt kommt, ist das schon deine Schuld mMn.

gentoo/emerge kann daran dann auch nichts machen, weil es nicht dafür zuständig ist irgendwelche dependencies aus Paketen raus zu patchen. da musst du dich schon an den/die paket maintainer direkt wenden...

----------

## alexander_ro

Du hast da schon recht ich meinte ja nicht das es ein Portage Problem ist oder von Gentoo. Die Problemverursacher sind wo anders zu suchen nur ich bin es auch nicht.

Aktuell habe ich es noch Geschafft Projekte die llvm Nutzung erzwingen mit alternativen oder eigener Software zu ersetzen. Das wird aber schwerer mit der Zeit ... leider. Vielleicht kommt noch der Tag wo ich es installieren muss aber dann nicht weil ich es gut finde sondern weil es mir andere Aufzwingen. Ich dachte immer der Sinn Freier Software ist der das ich nur Nutze was ich gut finde. Leider wurde diese Freiheit den Interessen der Konzerne geopfert.

----------

## Christian99

Der Sinn freier Software ist es, dass man den Quellcode einsehen und selbst modifizieren/nutzen kann (so ganz kurz), nicht das man sich alles frei aussuchen kann.

Es ist nämlich mit einer gewissen Arbeit verbunden solche wahlfreiheiten umzusetzen, die jemand leisten muss. Und man kann niemanden dazu zwingen das zu tun.

----------

## alexander_ro

Doch die Wahlfreiheit ist schon auch ein Bestandteil ohne die ist es nicht mehr wirklich besser als Kommerzielle Software. Die Wahlfreiheit entsteht zum großen Teil durch den offenen Sourcecode. Die Menge an USE-Flag oder Kernel Optionen belegt das ja auch das man viel wählen kann (noch). Offensichtlich war ja nicht nur ich der Meinung das man zwischen zwei JavaScript Interpretern wählen können sollte.

Es macht aber auch Arbeit llvm oder anderes erst als Zwang einzubauen. Ich sage ja nicht das die es tun müssen sondern das es Schade ist wenn nur noch gemacht wird was Konzernen wie Google Facebook nutzt. Die Milliarden mit der Arbeit der Projekte verdienen und nicht einmal den Tropfen auf den Heißen Stein zurück liefern.

----------

## mike155

 *alexander_ro wrote:*   

> Technisch gesehen ist llvm ein Irrweg

 

Wie kommst Du denn darauf? llvm ist ein moderner Baukasten, mit dem man Compiler entwickeln kann. Compiler-Entwickler lieben llvm - es nimmt ihnen viel Zeit und Arbeit ab.

----------

## alexander_ro

Schau ihn Dir an und überlege was die Probleme sind beim Compiler bauen.

Dann wird Dir vielleicht auffallen das die die Probleme verwalten aber nicht lösen. Auch eine Abstraktionsschicht über die andere zu bauen um die Abstraktion zu abstrahieren ist Mäßig intelligent. In der IT ist das aber weit verbreitet. Die Abstraktion zu abstrahieren gut ist es deshalb noch lange nicht. Die Fehler nehmen zu die Menschen die es noch verstehen nehmen ab und die Laufzeiten Eskalieren. Auch Compiler sollte man Effizient bauen können Rust ist das Glanzbeispiel der nicht mehr Nutzbaren Tools in Bereichen ohne Supercomputer. Ich konnte den nicht bauen mit 16GB Speicher keine Ahnung ab wann er zu bauen ist. 100GB 1000? !0 Kerne 100? 

Was macht aber ein Baukasten für Compilerbau dann bei einem Interpreter wie JavaScript?

----------

## Christian99

 *alexander_ro wrote:*   

> Doch die Wahlfreiheit ist schon auch ein Bestandteil ohne die ist es nicht mehr wirklich besser als Kommerzielle Software. Die Wahlfreiheit entsteht zum großen Teil durch den offenen Sourcecode. Die Menge an USE-Flag oder Kernel Optionen belegt das ja auch das man viel wählen kann (noch). Offensichtlich war ja nicht nur ich der Meinung das man zwischen zwei JavaScript Interpretern wählen können sollte.
> 
> Es macht aber auch Arbeit llvm oder anderes erst als Zwang einzubauen. Ich sage ja nicht das die es tun müssen sondern das es Schade ist wenn nur noch gemacht wird was Konzernen wie Google Facebook nutzt. Die Milliarden mit der Arbeit der Projekte verdienen und nicht einmal den Tropfen auf den Heißen Stein zurück liefern.

 

Naja, man will irgendein feature haben, dass kann man dann selber machen oder schauen was schon da ist, dass man einbinden kann. Der jeweilige Entwickler entscheidet sich oder das Entwicklungsteam, je nach projekt, und dann wird es gemacht. wenn man dann noch eine Alternative implementierung haben will ist es noch zusätzliche arbeit, die erst mal nicht viel neues bringt.

Wenn du das machen möchtest, dann kannst du das gerne machen. Das ist freie Software. Aber einen Anspruch darauf, dass es jemand für dich macht hast du nicht...

 *Quote:*   

> Schau ihn Dir an und überlege was die Probleme sind beim Compiler bauen.
> 
> Dann wird Dir vielleicht auffallen das die die Probleme verwalten aber nicht lösen. Auch eine Abstraktionsschicht über die andere zu bauen um die Abstraktion zu abstrahieren ist Mäßig intelligent. In der IT ist das aber weit verbreitet. Die Abstraktion zu abstrahieren gut ist es deshalb noch lange nicht. Die Fehler nehmen zu die Menschen die es noch verstehen nehmen ab und die Laufzeiten Eskalieren. Auch Compiler sollte man Effizient bauen können Rust ist das Glanzbeispiel der nicht mehr Nutzbaren Tools in Bereichen ohne Supercomputer. Ich konnte den nicht bauen mit 16GB Speicher keine Ahnung ab wann er zu bauen ist. 100GB 1000? !0 Kerne 100?
> 
> Was macht aber ein Baukasten für Compilerbau dann bei einem Interpreter wie JavaScript?

 

hm, also ich kann rust ganz gut nutzen  :Smile:  sowohl den compiler zu bauen (mit 8 Cores und 16GB arbeitsspeicher in etwas über einer Stunde), als auch zum selber programmieren.

Spidermonkey hat einen JIT, vielleicht dafür? Aber nur eine Vermutung. Hab mich noch nie mit den internals von spidermonkey beschäftigt.

----------

## alexander_ro

Ich habe ja nicht gesagt das die das tun müssen. Die dürfen ja gerne selber entscheiden wie sie das machen. Ich muss es aber nicht gut finden. Daher die Maskierung vom llvm Paket.

Diese Baukästen machen alles billiger = weniger Arbeit besser machen die es nicht.

Die Autobauer haben seit Jahrzehnten Baukästen ... Conti Siemens Bosch liefern die Systemkomponenten die Industrie nagel es zusammen. Heute ist es egal was man für ein Auto kauft die sind Technisch Identisch durchschnittlich Perfektion gibt es nicht mehr weil es die Details die die Perfektion ausmachen nicht gibt. Das können Baukästen nicht leisten. Die Innovation geht Richtung Null. So große Projekte sind wie Konzerne oder Regierungen schwerfällig und gemacht wird was der Mächtigste sagt nicht was Technisch gut wäre.

----------

## Christian99

 *alexander_ro wrote:*   

> Ich habe ja nicht gesagt das die das tun müssen. Die dürfen ja gerne selber entscheiden wie sie das machen. Ich muss es aber nicht gut finden. Daher die Maskierung vom llvm Paket.

 

dann darfst du dich aber nicht wundern wenn was nicht geht.

"ich kauf mir ein auto, aber benzin mag ich nicht, also tank ich nicht"

----------

## alexander_ro

Der Vergleicht hinkt nicht nur sondern ist schon ein Einbeiniger Lahmer ...

Ich habe mich weniger gewundert sondern nach einer Lösung gesucht. Die nette Menschen hier mir auch Mitgeteilt haben.

Wenn müsste ich dann die CPU nicht mögen die ist ähnlich wichtig wie Benzin/Diesel oder Strom. Die Aufzählung zeigt aber schon wenn ich das richtige Auto kaufe kann ich auch Benzin meiden. Wenn ich die richtige Software installiere kann ich auch llvm Meiden zumindest noch ich hoffe das bleibt so.

----------

