# via ebuild mehrere Repos auschecken?

## 3PO

Hallo Zusammen,

ist eigentlich möglich, via ebuild mehrere Repos auszuchecken?

Beispiel:

in "EGIT_REPO_URI" steht das eigentliche Paket und weiter unten z.B. in "src_prepare" möchte aus einem anderen Repo einen Patch herunterladen und anwenden.

Ist soetwas möglich und falls ja, wie?

----------

## mrsteven

Hallo,

auch wenn es deine Frage nicht direkt beantwortet, aber das übliche Vorgehen bei kleineren Patches ist eigentlich, dass man die in das files-Verzeichnis des Ebuilds legt und dann in src_prepare einfach ein

```
epatch "${FILESDIR}/${P}-foo.patch
```

macht. Bei nur einem Patch ist das sicher einfacher und effizienter, als zwei Repositories zu klonen.

----------

## 3PO

Dass es mit epatch geht ist mir auch klar, aber das war nicht die Frage.

----------

## franzf

Es sollte gehen, das Patch via SRC_URI herunterzuladen und dann epatch in src_prepare nicht aus ${FILESDIR} zu füttern sondern aus ${DISTDIR}.

----------

## mv

Die entsprechenden Eclasses für die verschiedenen VC-Systeme (git*, cvs, ...) sehen leider nicht vor, was Du willst (außer Deine Quellen stammen zufälligerweise von vorschiedenen VC-Systemen).

Für das VC-System monotone gibt es eine Eclass, die das kann, im mv overlay (denn das Paket "games-rpg/magus" dort benötigt Sourcen aus verschiedenen Quellen), aber eben nur für monotone, und das ist nicht im offiziellen Gentoo-Repository (für monotone gibt es gar keine Eclasse im Gentoo-Repository).

Du musst Dir wohl selbst eine passende Eclasse schreiben (oder es one-shot im Ebuild manuell erledigen).

----------

## 3PO

Ich habe es jetzt anders gelöst, ich habe es mit Plugins gemacht.

foo-bar/lala

foo-bar/lala-Plugin-abc

foo-bar/lala-Plugin-123

Was mir allerdings noch fehlt ist, dass wenn "foo-bar/lala" neu gebaut wird, auch hinterher jedes Mal(!) die Plugins auch neu gebaut werden.

Ich habe es mit "PDEPEND" versucht, das scheint aber nicht zu funktionieren.  :Sad: 

Hat Jemand eine Idee, wie man das regeln könnte?

----------

## 3PO

Niemand eine Idee dazu?

----------

## schmidicom

Schau dir mal die ebuilds von lightdm und dessen greeter an die verhalten sich nämlich genau so.

----------

## mv

 *schmidicom wrote:*   

> Schau dir mal die ebuilds von lightdm und dessen greeter an die verhalten sich nämlich genau so.

 

Das erscheint Dir wahrscheinlich nur zufällig so, weil Du sie nur bei Versions-Bumps neu baust.

Ich denke nicht, dass das gewünschte Verhalten bei Live-Ebuilds (ohne Versionen- oder Subslot-Bumps) erreicht werden kann.

----------

## franzf

 *mv wrote:*   

>  *schmidicom wrote:*   Schau dir mal die ebuilds von lightdm und dessen greeter an die verhalten sich nämlich genau so. 
> 
> Das erscheint Dir wahrscheinlich nur zufällig so, weil Du sie nur bei Versions-Bumps neu baust.
> 
> Ich denke nicht, dass das gewünschte Verhalten bei Live-Ebuilds (ohne Versionen- oder Subslot-Bumps) erreicht werden kann.

 

Wir können überhaupt nichts sagen, weil die Ausgangsfrage schon recht nebulös war und am eigentlichen Thema vorbei ("patch in src_prepare" vs "externes Plugin als eigenes Paket"). Ich weiß nicht, wie ernst das "EGIT_REPO_URI" im Ausgangspost genommen werden kann. Falls es sich tatsächlich um live-ebuilds handeln sollte und falls es nicht möglich ist ABIs korrekt im subslot zu handhaben (was ich annehme) sehe ich keine automatische Lösung sondern nur ein manuelles revdep-rebuild.

----------

## mv

 *franzf wrote:*   

> Wir können überhaupt nichts sagen, weil die Ausgangsfrage schon recht nebulös war

 

Für mich ist die Frage sehr klar, weil es genau dieses Problem beim Ebuidl von magus gab:

Upstream stellt das gewünschte Programm nicht in einem Repository zur Verfügung, das alles enthält, sondern bestimmte Komponenten (Libraries/Plugins/Patches/... etc.) werden in einem getrennten Repository gelagert. Trotzdem sind diese Repositories nicht unabhängig voneinander, d.h. Syncen und Neubauen des Haupt-Repositories wird nicht funktionieren, solange man nicht vorher die anderen Repositories auf den neuesten Stand gebracht und während des Bauens zur Verfügung hat.

Anscheinend hat sich 3PO entschlossen, die Libraries/Patches/was-auch-immer in einem getrennten Paket als Source-Code zu installieren, um sie dann anschließend beim emergen des Hauptprogramms zur Verfügung zu haben (oder vielleicht auch umgekehrt).

Da gibt es aber dann eben das Problem, dass bei einem erneuten Emergen des Haupt-Repositories (mit EVCS_OFFLINE='') nicht zwangsläufig die anderen Repositories erneut emerget werden müssen.

----------

## franzf

 *mv wrote:*   

> Anscheinend hat sich 3PO entschlossen, die Libraries/Patches/was-auch-immer in einem getrennten Paket als Source-Code zu installieren, um sie dann anschließend beim emergen des Hauptprogramms zur Verfügung zu haben (oder vielleicht auch umgekehrt).

 

Es schaut eher aus als wäre es umgekehrt, und da könnte man sehrwohl mit subslots und =-Operator arbeiten, so lange es kein live-ebuild ist (ginge auch, würde aber mehr Aufwand bedeuten). Und ich bin mir nichtmal sicher, dass es live-ebuilds sind.

3PO kannst du mal bitte genau sagen, was du versuchst? Am besten gleich sagen, welches Paket du wie installieren willst, dann können wir auch konkrete Tips geben.

----------

## 3PO

 *franzf wrote:*   

> [...] 3PO kannst du mal bitte genau sagen, was du versuchst? Am besten gleich sagen, welches Paket du wie installieren willst, dann können wir auch konkrete Tips geben.

 

Mir geht es darum: --> https://github.com/3PO/3PO-overlay/tree/master/media-tv

Dort gibt es ein Paket "epgd". Ich will nun, dass wenn epgd neu gebaut wird, automatisch auch die Plugins (epg-plugin-*) neu gebaut werden.

----------

## franzf

Soweit ich sehe hat da jeder commit eine eigene Version (wie es auch bei vim der Fall ist). Du könntest also auch regelmäßig neue Snapshots ins Overlay packen und denen einen Subslots verpassen, z.B. beim aktuellen Stand "2016-06-25: version 1.0.106" im Ebuild einen SLOT="1/106". Die Plugins haben dann als Abhängigkeit "media-tv/epgd:=" stehen und sollten dann automatisch neu gebaut werden können.

epgd-9999 kann so aber leider keinen automatischen rebuild auslösen, da der SLOT (und damit subslot) händisch im ebuild eingetragen werden muss und das irgendwie nahezu unmöglich ist, das beim live-ebuild immer aktuell zu halten  :Wink:  Da brauchst du dann ein revdep-rebuild. Evtl. reicht dir aber auch eine pkg_postinst-Meldung, die den User auffordert die Plugins neu zu bauen.

Auch von der Code-Seite her ein interessantes Projekt, dieses epgd... "CC=g++" und auch die cList-Implementierung in svdrclient.h (Verebung + template)  :Wink:  Schaut mir teilweise nach "C mit Klassen, aber richtig" aus.

----------

## 3PO

Nun ja, zu jeder Revision ein ebuild zu erstellen, bin ich zu faul, denn deshalb war ja auch eingangs die Idee, einfach mehrere Repos auszuchecken. 

Das es vermutlich so oder so nur ein paar User geben wird, werde ich einfach empfehlen, es so zu installieren/updaten:

```
emerge -v $(qlist -IC epgd)
```

BTW: Der Code von EPGd ist nicht von mir, ich habe nur das ebuild gebastelt.  :Wink: 

----------

## kernelOfTruth

Das muss irgendwas mit Slots zu tun haben oder so

wenn z.b. xorg-server neu gebaut wird, werden automatisch die Treiber auch neu gebaut (forced rebuild)

eventuell findet sich dazu was unter:

https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq#TOC-When-does-a-dependency-cause-a-rebuild-

https://devmanual.gentoo.org/general-concepts/slotting/

alternativ mal im IRC nachfragen

----------

