Wie macht man ein Update/Upgrade von installierten Pkg's in NetBSD (suber)???

SierraX schrieb:
Jetzt bin ich etwas verwirrt. Willst du die pkgsrc updaten oder die installierten pakete?

Guck auch mal auf http://www.pkgsrc.org vieleicht kommst du dabei auf brauchbare ideen fuer deinen bedarf.

Ich bin Selberbauer. Ich möchte im pkgsrc-Releasezyklus pkgsrc auf den aktuellen (nicht current) Stand bringen, meine Pakete bauen und dann auf die Rechner verteilen.

Bei meiner Fragestellung geht es also zunächst nur um pkgsrc updaten.
 
CAMISOLITE schrieb:
....
Ihr habt schon verstanden, daß ich mit Release nicht das NetBSD-Release meine ???
Achso! Nein, das hatte ich dann falsch verstanden... :ugly:

Da weiss ich nicht so genau, aber sieh mal unter "/usr/pkgsrc/doc/" nach. Evtl. gibt es in einer von den Dateien einen Anhaltspunkt für die RELEASE-Version des Tree's.
 
das sollte es sein...

Ich würde einfach per Script einen FTP-Download der entsprechenden Archivdatei machen, entweder klappt er (wenn es das RELEASE schon gibt) oder er schlägt fehl:

je nach Vorliebe, diese:
ftp://ftp.netbsd.org/pub/pkgsrc/2005Q3/pkgsrc-2005Q3.tar.bz2
oder diese:
ftp://ftp.netbsd.org/pub/pkgsrc/2005Q3/pkgsrc-2005Q3.tar.gz

Automatisieren lässt sich das am besten mit den Programmen "ncftp" oder "wget" ("wget -c" kann sogar abgebrochene Downloads wieder aufnehmen und weiterführen).

Willst Du kein weiteres Programm installieren, ist es auch möglich mit ein paar Tricks den Standard-FTP-Clienten "fern zu steuern" (auf FreeBSD getestet, hatte NetBSD nicht zur Hand):


# vi pkgsrc-auto-downoad.sh

ftp ftp://ftp:ftp@ftp.netbsd.org/pub/pkgsrc/2005Q3/ << EOF
bin
get pkgsrc-2005Q3.tar.bz2
by

EOF

:D

P.S.: Die Leerzeile vor dem zweiten "EOF" muss sein!
 
und natuerlich koenntest du auch einfach ein
Code:
echo 'ls ' | ftp -V ftp://ftp.netbsd.org/pub/pkgsrc/
und die ausgabe dann nach ordnern filtern die in der form "JahrQx" benannt sind (ein "| grep Q" dahinter duerfte das machen ). dann musst du nurnochc gucken welcher von denen am neusten ist (obowhl ueberhaupt nur selten mehrere existieren, glaube ich).
 
Klingt gut

@soul_rebel && xbit:

Gute Ideen ! Teste ich mal aus. Auf dem ftp-Server ist glaube ich immer nur die aktuelle Version, aber Vorsicht ist die Mutter der Porzellankiste ...

Wen's interessiert, hier mein erwähntes Shell-Skript:

Code:
#!/bin/sh

#=== STEP 1: detect current year and month 
varYear="`date +%Y`"
varMonth="`date +%m`"

#=== STEP 2: calculate pkgsrc related quarter of a year
#--- * increase month by 1 because pkgsrc is usually relesed with such a delay
#---   example: 2005Q3 is assumed to become stable by Nov. 2005 (not Oct. 2005)
#--- * decrease quarter by 1 because pkgsrc is released at the end of a quarter
#---   example: a Q1 is released in Mar./Apr. and thus available earliest for Q2 
varQuarter="`expr \( \( ${varMonth} + 1 \) / 3 \) - 1`"

#=== STEP 3: check if quarter is a valid value in the range of 1 to 4
if [  ${varQuarter} -lt 1 ]; then
	#--- quarters less than 1 are in the previous year 
	varYear="`expr ${varYear} - 1`"
	#--- quarters less than 1 have do be tuned to valid values
	varQuarter="`expr ${varQuarter} + 4`"
fi

#=== STEP 4: format cvs tag
varTag="pkgsrc-${varYear}Q${varQuarter}"
echo ${varTag}
 
Erfolg

soul_rebel schrieb:
und natuerlich koenntest du auch einfach ein
Code:
echo 'ls ' | ftp -V ftp://ftp.netbsd.org/pub/pkgsrc/
und die ausgabe dann nach ordnern filtern die in der form "JahrQx" benannt sind (ein "| grep Q" dahinter duerfte das machen ). dann musst du nurnochc gucken welcher von denen am neusten ist (obowhl ueberhaupt nur selten mehrere existieren, glaube ich).

Nun, das grep allein reicht noch nicht, weil das ls eine Ausgabe wie ls -l liefert. Ich wurde aber von meinem Freund awk geholfen.

Es ist zwar immer nur ein Verzeichnis mit dem aktuellen Release vorhanden, aber sicherheitshalber gehe ich davon aus, daß ich da auch mal mehrere Verzeichnisse vorfinden werde.

Alles im allen ist die Lösung nun deutlich kompakter und beruht nicht mehr auf Annahmen meinerseits (also Quartalsende + 1 Monat Puffer) sondern auf dem tatsächlichen Stand des pkgsrc-Projekts. Hier meine Lösung:

Code:
echo "pkgsrc-`echo 'ls' | ftp -V 'ftp://ftp.netbsd.org/pub/pkgsrc/' | grep Q | awk '{print \$9}' | sort | tail -n 1`"

Vielen Dank an soul_rebel, der den entscheidenen Anstoß zu dieser Lösung gegeben hat. :)


Die CVS-Lösung probiere ich auch (irgendwann) mal, wird aber vielleicht etwas frickeliger.
 
Hallo,

ich will mich hier nicht unbedingt einmischen bzw. wichtig tun, aber ich mache in letzter Zeit sehr viele Updates, z.T. mit Crosscompiling um alten Maschinen so die Arbeit des Übersetzens zu ersparen.

Ich mach's so:

1. Eintrag in .profile

export CVS_RSH ssh
export CVSROOT anoncvs@anoncvs.netbsd.org:/cvsroot

2. Code ziehen

cd /usr
cvs checkout -r netbsd-2-1-RELEASE -PA src
bzw. für X11R6-Sources
cvs checkout -r netbsd-2-1-RELEASE -Pa xsrc

oder

cd /usr/src
cvs update -r netbsd-2-1-RELEASE -Pd
bzw. für X11R6-Sources
cd /usr/xsrc
cvs update -r netbsd-2-1-RELEASE -Pd

Es ist korrekt, ein Update macht nur ein Update des vorher installierten Systems, will man eine andere Version, muß man meiner Meinung nach checkout nutzen - es hatte bei mir immer geklapt und ich habe öfters mal auf dem Athlon die 2.0 oder 2.1 bzw. jetzt die 3.0rc* compiliert und Sets gebaut!

Der Bau der Distribution ist ja bekannt:

Ohne Crosscompiling einfach in /usr/src

./build.sh tools kernel=GENERIC distribution sets eingeben bzw. mit Crosscompiling
./build.sh -m portname -a portname tools kernel=GENERIC distribution sets eingeben.

Ich würde beim ersten build auch immer den GENERIC bauen und den korrekten Lauf dessen checken und später erst einen angepassten Kernel bauen!

Dann nur noch die Distribution installieren, ich mache das mit den gebauten Sets immer:

cd /
for i in PATH_TO_SETS/*.tgz do
tar xpvfz $i
done

Das Set etc.tgz ist eine Frage für sich und games.tgz nun ja, wer braucht das!!!

Ich hoffe, es war nicht am Thema vorbei geschrieben!

Gruß Frank
 
steinlaus schrieb:
@franco98
*räusper* Ähm danke für deinen Beitrag... aber es geht um pkgsrc, nicht um NetBSD direkt... :)

Klar, jetzt sehe ich's auch, war ein Versehen!

Nun make update denke ich!

Make update deinstalliert zuerst das Packet und alle Abhängigkeiten (dauert lange) und dann kommt die Neuinstallation (dauert noch länger)!

Wer will sich das z.B. bei KDE antun, nur um von 3.3.2 z.B. auf 3.4.2 zu kommen?

Gruß Frank
 
franco98 schrieb:
Klar, jetzt sehe ich's auch, war ein Versehen!

Nun make update denke ich!

Make update deinstalliert zuerst das Packet und alle Abhängigkeiten (dauert lange) und dann kommt die Neuinstallation (dauert noch länger)!

Wer will sich das z.B. bei KDE antun, nur um von 3.3.2 z.B. auf 3.4.2 zu kommen?

Gruß Frank
Liest von Euch jemand auch mal den Anfang bevor er postet?

Mit tatkräftiger Unterstützung von @kaishakunin haben wir das Problem schon auf den ersten drei Seiten lösen können. Allerdings hat @pierre dann auf der Seite 4 in Post Nr. 56 eine Lösung vorgestellt, die mir etwas besser gefällt.
Das wird zusammenfassend auf Seite 4 in Post Nr. 60 von mir nocheinmal dargestellt.
:D
 
Mein Skript

So, hatte vor ca. ner Woche diesen Thread gelesen und hab mich Erinnert, das ich auch mal ein Skript schreiben wollte. :ugly:

Nun ja, wenigstens hab ich wieder lust bekommen und hab 'mein' Skript mal angehängt.

Dem Skript muss ein Packagename übergeben werden, ich hab kein automatisches Update von *allen* Packeten geschrieben und werd das auch schön lassen, da ich wahrscheinlich in der Testphase schon meine kompletten pkg's zerschießen würde. :rolleyes:

Aufruf des skripts:
Code:
./pkg_update.sh sudo-1.6.8pl9nb2
Diesen 'kompletten' Packagenamen + Versionnummer bekommt man mit
Code:
pkg_info -a | grep "$PKG_NAME"
Also z.b.
Code:
$ pkg_info -a | grep sudo
sudo-1.6.8pl12nb1   Allow others to run commands as root

Das skript holt sich aus /var/db/pkg/$PKG_NAME/+BUILD_INFO den $PKG_PATH, also z.b. security/sudo
Dann schaut es im Makefile von 'sudo' nach dependencys und schau bei denen ebenfalls nach dependencys bis es anfängt die dependencys zu bauen, bis es beim 'eigentlichen' packet wieder angelang ist.

FIXME: Das skript baut die dependency auch, wenn die version schon voll genügt. Ich hab leider keine ahnung wie ich herausbekommen kann, welche version das Packet braucht und so gegebenfalls diese Dependency zu übergehn, was das updaten sehr beschleunigen würde.

U.a holt es sich auch aus der +BUILD_INFO die, wenn vorhanden, PKG_OPTIONS, d.h. das Packet wird beim updaten mit den selben PKG_OPTIONS gebaut wie vorher.

Bei mir funktioniet das skript und hat, bis jetzt, noch nix zerschossen ;)

3 Variablen müssen am Anfang definiert werden:
Code:
#############################################
#
# "must" defined variables

[ "$PKGSRCDIR" ] || PKGSRCDIR="/usr/pkgsrc"
[ "$PKG_DB" ] || PKG_DB="/var/db/pkg"
[ "$MAIL_ADDR" ] || MAIL_ADDR="root"
Fehler werden zu MAIL_ADDR gemailt (mit dem kommando 'mail')
PKGSRCDIR ist meistens /usr/pkgsrc
PKG_DB ist auch eigentlich /var/db/pkg

Falls jemand Fehler u.ä. findet oder einfach mal meckern möchte, so soll er dies doch tun ;) :)

btw, das ist meiner erstes *richtiges* shell skript was mehr als 5 zeilen und 2 'if' abfragen hatt. :cool:

Es basiert u.a. auf 'gwak', 'sed' und 'grep' sind AFAIK immer installiert

MfG
 

Anhänge

  • pkg_update.sh.txt
    6,6 KB · Aufrufe: 303
Zuletzt bearbeitet:
Zurück
Oben