Gentoo PatchFilesspace
Mad (Diskussion | Beiträge) |
Hulk (Diskussion | Beiträge) K (Typo) |
||
(Eine dazwischenliegende Version von einem Benutzer wird nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | Um die Nachhaltigkeit von Patches zu gewährleisten müssen Patches auch noch verfügbar sein wenn der Entwickler dieser Patches schon neue bereitgestellt hat und die alten Patches von seiner Webseite löscht. Leider ist die | + | Um die Nachhaltigkeit von Patches zu gewährleisten müssen Patches auch noch verfügbar sein, wenn der Entwickler dieser Patches schon neue bereitgestellt hat und die alten Patches von seiner Webseite löscht. Leider ist die allgemein üblich. |
Wie aus diesem [http://www.vdr-portal.de/board/thread.php?threadid=30587 THREAD] auf vdr-portal.de hervorgeht ist mir das passiert. | Wie aus diesem [http://www.vdr-portal.de/board/thread.php?threadid=30587 THREAD] auf vdr-portal.de hervorgeht ist mir das passiert. | ||
− | Daher habe ich | + | Daher habe ich erst einmal auf einem meiner Kisten ein bisschen Filespace mit Uploadscript bereitgestellt. Hier sollten alle Ebuild Entwickler die Patches uploaden und die URL in Ihren Ebuilds verwenden. |
− | Ein Zugang zum Filesuploaden | + | Ein Zugang zum Filesuploaden gibt es bei mir (mad @ cc . fh - luh . de) per Mail, weitere Informationen sind im o.g. Thread des [[VDR Portal]] zu finden. |
− | Inzwischen habe ich ein | + | Inzwischen habe ich ein Skript welches alle Dateien die VDR Ebuilds brauchen einmal die Woche von den entsprechenden Fileserver holt. Damit sind zumindest erst einmal alle aktuellen Dateien im Filespace. |
− | Es müssen nur | + | Es müssen nur Dateien für neue Ebuilds hoch geladen werden. |
− | Um das Ganze abzurunden habe ich die Downloadlocation '''mirror://vdrfiles/''' eingeführt, die im Moment nur auf gentoo.fh-luh.de zeigt. Somit sind aber spätere Umzüge auf andere Fileserver kein Problem. | + | Um das Ganze abzurunden habe ich die Downloadlocation '''mirror://vdrfiles/''' eingeführt, die im Moment nur auf gentoo.fh-luh.de zeigt. Somit sind aber spätere Umzüge auf andere Fileserver kein Problem. Realisiert wird das durch den Eintrag in der Datei [http://www.gentoo.de/viewcvs/*checkout*/profiles/thirdpartymirrors thirdpartymirrors] die im gentoo-de und gentoo-merged Rsync-Tree auf rsync16.de.gentoo.org zur Verfügung steht. |
− | Ich | + | Ich weiß im Moment nicht wie sich das verhält, wenn gentoo-de z.B. nach /usr/local/portage gesynced wird. Das thirdpartymirror File liegt dann dort, ob es aber benutzt wird weiß ich nicht. |
− | Da das Download | + | Da das Download Skript für die Dateien im Moment noch in die Ebuilds schaut was geladen werden soll können die Ebuilds nicht komplett auf mirror:// umgestellt werden. Ich denke ein sicherer Weg ist es erst die original URL und danach die mirror URL anzugeben. Die Ebuilds können das handeln. |
Beispiel: | Beispiel: | ||
Zeile 22: | Zeile 22: | ||
mirror://vdrfiles/lumiere/lumiere-0.2.tar.gz" | mirror://vdrfiles/lumiere/lumiere-0.2.tar.gz" | ||
</pre> | </pre> | ||
− | + | Diese Dateien sind weder im original noch auf dem mirror vorhanden, daher hab ich diese Ebuild genommen um das Ganze zu testen. RESTRICT="nomirror" (wer die eclasses nimmt, braucht das nicht) da wahrscheinlich keine der Dateien bei Gentoo.org auf dem Mirror liegt, das beeinflusst nicht die Funktion des mirror://vdrfiles/ Prefixes. | |
− | Ich bitte ALLE VDR Ebuild Entwickler die Ebuilds auf diese Methode anzupassen da bei den vielen Updates der VDR | + | Ich bitte ALLE VDR Ebuild Entwickler die Ebuilds auf diese Methode anzupassen, da bei den vielen Updates der VDR Gemeinde die Ebuilds nach einiger Zeit möglicherweise nicht mehr funktionieren. |
--[[Benutzer:Mad|Mad]] 11:56, 26. Mär 2005 (CET) | --[[Benutzer:Mad|Mad]] 11:56, 26. Mär 2005 (CET) |
Aktuelle Version vom 12. September 2012, 17:15 Uhr
Um die Nachhaltigkeit von Patches zu gewährleisten müssen Patches auch noch verfügbar sein, wenn der Entwickler dieser Patches schon neue bereitgestellt hat und die alten Patches von seiner Webseite löscht. Leider ist die allgemein üblich.
Wie aus diesem THREAD auf vdr-portal.de hervorgeht ist mir das passiert.
Daher habe ich erst einmal auf einem meiner Kisten ein bisschen Filespace mit Uploadscript bereitgestellt. Hier sollten alle Ebuild Entwickler die Patches uploaden und die URL in Ihren Ebuilds verwenden.
Ein Zugang zum Filesuploaden gibt es bei mir (mad @ cc . fh - luh . de) per Mail, weitere Informationen sind im o.g. Thread des VDR Portal zu finden.
Inzwischen habe ich ein Skript welches alle Dateien die VDR Ebuilds brauchen einmal die Woche von den entsprechenden Fileserver holt. Damit sind zumindest erst einmal alle aktuellen Dateien im Filespace. Es müssen nur Dateien für neue Ebuilds hoch geladen werden.
Um das Ganze abzurunden habe ich die Downloadlocation mirror://vdrfiles/ eingeführt, die im Moment nur auf gentoo.fh-luh.de zeigt. Somit sind aber spätere Umzüge auf andere Fileserver kein Problem. Realisiert wird das durch den Eintrag in der Datei thirdpartymirrors die im gentoo-de und gentoo-merged Rsync-Tree auf rsync16.de.gentoo.org zur Verfügung steht.
Ich weiß im Moment nicht wie sich das verhält, wenn gentoo-de z.B. nach /usr/local/portage gesynced wird. Das thirdpartymirror File liegt dann dort, ob es aber benutzt wird weiß ich nicht.
Da das Download Skript für die Dateien im Moment noch in die Ebuilds schaut was geladen werden soll können die Ebuilds nicht komplett auf mirror:// umgestellt werden. Ich denke ein sicherer Weg ist es erst die original URL und danach die mirror URL anzugeben. Die Ebuilds können das handeln.
Beispiel:
RESTRICT="nomirror" SRC_URI="http://brain.shacknet.nu/lumiere-0.2.tar.gz mirror://vdrfiles/lumiere/lumiere-0.2.tar.gz"
Diese Dateien sind weder im original noch auf dem mirror vorhanden, daher hab ich diese Ebuild genommen um das Ganze zu testen. RESTRICT="nomirror" (wer die eclasses nimmt, braucht das nicht) da wahrscheinlich keine der Dateien bei Gentoo.org auf dem Mirror liegt, das beeinflusst nicht die Funktion des mirror://vdrfiles/ Prefixes.
Ich bitte ALLE VDR Ebuild Entwickler die Ebuilds auf diese Methode anzupassen, da bei den vielen Updates der VDR Gemeinde die Ebuilds nach einiger Zeit möglicherweise nicht mehr funktionieren.
--Mad 11:56, 26. Mär 2005 (CET)