[PATCH 1/2] added removal of /src/dl to clean function of buildscript
Tobias Klaus
tk+ff at meskal.net
Mo Jan 9 23:10:40 CET 2017
Hey,
auch wenn ich dir Recht geben muss, dass es etwas inkonsistent ist die Repos
zu löschen und die Downloads nicht, bin ich trotzdem dagegen das src/dl zu
löschen.
Dass man mal im openwrt arbeitet und den Überblick verlieert sehe ich ja ein,
aber an den Paket-tarballs patchen ist schon recht ungewöhnlich. Dafür würde
ich ungern standardmäßig alle Pakete wegwerfen.
Andere Projekte unterscheiden hier auch unterschiedliche "clean"-Arten.
Vielleicht sollten wir auch zwischen "clean" und "distclean" unterscheiden.
Ersteres würde nur versuchen die Repos sauber zu kriegen und $target leer
machen, würde also versuchen Traffic und Zeit zu sparen und zweiteres würde
dann wirklich den "Auslieferungszustand" wieder herstellen.
Viele Grüße
Tobias
Am Samstag, 7. Januar 2017, 14:59:48 CET schrieb Jan Kraus:
> Hi Tim,
>
> Am Freitag, den 06.01.2017, 11:21 +0100 schrieb Tim Niemeyer:
> > Am Freitag, den 06.01.2017, 11:05 +0100 schrieb mayosemmel:
> > > Hi Tim,
> > >
> > > Ich hatte in dem download Ordner rumgepatcht und nach einem "clean"
> > > war es immer noch gepatcht.
> >
> > Wie das? Die Downloads sind doch mit einer Prüfsumme gesichert?
>
> Die Prüfsummen werden anscheinend nur direkt nach dem Download geprüft.
>
> > > Das hat mich einiges an Zeit gekostet, den Fehler zu finden.
> >
> > Verstehe ich.. Normalerweise fummelt man ja auch nicht an den Downloads
> > rum. ;)
>
> Naja, beim basteln vllt. doch...
>
> > > Es ist eine gute Sache den Traffic zu sparen wenn ich einen regulären
> > > build mache.
> > > Wenn ich allerdings eine saubere Build Umgebung brauche und deshalb
> > > einen clean mache, sollte der auch alles bereinigen.
> >
> > Ne, es ist ja nur ein lokaler Download Cache. Ich sehe das Zeug unter
> > dl/ nicht als generierte Daten an. Daher auch kein Clean.
>
> Da muss ich dir etwas widersprechen. Bei einem clean werden auch alle
> git repos gelöscht( kernel, openwrt usw.). Es müsste nun entweder so
> sein, das diese auch erhalten bleiben oder der dl Ordner auch
> mitgelöscht wird.
> Ich sehe das clean so, das ich danach garantiert eine saubere Umgebung
> habe. Das ist aktuell leider nicht der Fall.
>
> > Um das Verhalten eines Download-Caches zu behalten, müssten wir das
> > irgendwie konfigurierbar machen. Es könnte so laufen, dass der User das
> > aktiviert und die Daten werden dann irgendwo unter ~/.cache/
> > gespeichert. Beim build werden die Daten dann aus dem Cache geladen bzw
> > aus dem Netz, wenn im Cache nicht vorhanden. Beim clean werden die Daten
> > nahe beim Repo gelöscht, der Cache bleibt erhalten.
>
> Wenn wir das so haben wollen, müssten die repos, die aktuell nach src
> geladen werden, ebenfalls da rein wandern. Aktuell ist es halt
> inkonsistent.
>
> > Ich weiß nicht, ob der Aufwand gerechtfertigt ist, nur weil du grad mal
> > im dl Folder rumgefrimmelt hast.. :P
>
> Wie oben schon geschrieben, haben wir aktuell einen inkonsistenten
> Status. Das würde ich gern beheben. Ob es nun aber den Aufwand wert ist,
> statt eines einfachen "rm" gleich ein Cache-System zu bauen...
>
> Grüße Jan
>
> > Tim
> >
> > > Grüße Jan
> > >
> > > Am 6. Januar 2017 09:55:56 MEZ schrieb Tim Niemeyer <tim at tn-x.org>:
> > > >Moin Jan
> > > >
> > > >Am Donnerstag, den 24.11.2016, 23:51 +0100 schrieb Jan Kraus:
> > > >> Signed-off-by: Jan Kraus <mayosemmel at gmail.com>
> > > >> ---
> > > >>
> > > >> buildscript | 2 +-
> > > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/buildscript b/buildscript
> > > >> index 25cf291..7d89fbb 100755
> > > >> --- a/buildscript
> > > >> +++ b/buildscript
> > > >> @@ -318,7 +318,7 @@ buildrelease() {
> > > >>
> > > >> }
> > > >>
> > > >> clean() {
> > > >>
> > > >> - /bin/rm -rf bin $builddir src/openwrt
> > > >> + /bin/rm -rf bin $builddir src/openwrt src/dl
> > > >
> > > >Was ist der Grund, warum du das entfernen willst?
> > > >
> > > >Letztlich scheint es eine gute Sache zu sein den Traffic zu sparen.
> > > >
> > > >Tim
Mehr Informationen über die Mailingliste franken-dev