Re: Eigenes deb-repository managen
Andreas Pakulat wrote: Es macht allerdings wirklich nur Archiv Verwaltung, es kennt kein Konzept von 'Queues' (wie incoming, NEW, etc.). Diese Teile muesste man sich dann selber zusammenstricken, was es flexibel einsetzbar macht. Grade sowas wie incoming brauch ich aber, NEW nicht so sehr, weil es vor allem darum geht das ich haeufiger mal offizielle Debian-Pakete selbst neu baue (mit anderen Optionen) bzw. auch eigene Programme ueber Pakete installiere. Und da es dafuer schon fertige Loesungen gibt ist halt reprepro aussen vor, weil es da fehlt... Hm. Das bauen und raufladen scheint hier nicht das Problem zu sein. Ein incoming processor zu schreiben ist nun auch nicht wirklich die wucht. Du solltest dir erst ueberlegen wie dein workflow wirklich ist, und was du wirklich brauchst. Das hatte ich eigentlich schon geschrieben: Ich baue ein Paket (entweder ein rebuild eines Paketes, ein eigenes Paket oder letztens hab ich fuer jmd. gnucash auf i386 gebaut und musste dafuer erst noch aqbanking bauen und dem chroot verfuegbar machen), lade es irgendwo ab und ein paar Minuten/Stunden spaeter hab ich entweder ne Mail ueber den Miserfolg oder kann ein aptitude update machen und das Paket installieren. Irgendwann gibts dann vllt. eine neue Version aus den Debian-Repos und ich brauche meine eigene Version nicht mehr und moechte das gesamte Paket endgueltig loeschen. Oder aber ich baue eine neue Version des Pakets, lade die hoch und krieg wieder ne Mail... Aha. Das hattest du bisher noch nicht wirklich so geschrieben. Was du da eigentlich vorhast ist schon sehr speziell. V.a. der teil mit 'Irgendwann gibts dann vllt. eine neue Version in debian...'. Diese Funktionalitaet bietet dir so gar kein tool, sondern ist Handarbeit. Und zum integrieren in eigene tools eignet sich reprepro wirklich ganz gut. Um etwas programmieren, sei es sh, perl oder python, wirst du fuer aufwendigere Sachen wohl kaum herumkommen. Wie schon angedeutet: Das Programmieren an sich ist weniger das Problem, eher die Sprache. Ich kann zwar Perl lesen und sh auch ein bisschen schreiben, aber in Python bin ich deutlich fitter... reprepro ist in C geschrieben, aber macht wirklich nur seine eigene Aufgabe: archivverwaltung. Den rest kannst du dir dann in python drumherum scripten. Greetings, Reinhard -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenes deb-repository managen
On 13.05.06 13:04:58, Reinhard Tartler wrote: Andreas Pakulat wrote: Das hatte ich eigentlich schon geschrieben: Ich baue ein Paket (entweder ein rebuild eines Paketes, ein eigenes Paket oder letztens hab ich fuer jmd. gnucash auf i386 gebaut und musste dafuer erst noch aqbanking bauen und dem chroot verfuegbar machen), lade es irgendwo ab und ein paar Minuten/Stunden spaeter hab ich entweder ne Mail ueber den Miserfolg oder kann ein aptitude update machen und das Paket installieren. Irgendwann gibts dann vllt. eine neue Version aus den Debian-Repos und ich brauche meine eigene Version nicht mehr und moechte das gesamte Paket endgueltig loeschen. Oder aber ich baue eine neue Version des Pakets, lade die hoch und krieg wieder ne Mail... Aha. Das hattest du bisher noch nicht wirklich so geschrieben. Was du da eigentlich vorhast ist schon sehr speziell. Naja, eigentlich dasselbe was bei Debian passiert... V.a. der teil mit 'Irgendwann gibts dann vllt. eine neue Version in debian...'. Diese Funktionalitaet bietet dir so gar kein tool, sondern ist Handarbeit. Und zum integrieren in eigene tools eignet sich reprepro wirklich ganz gut. Es geht nicht darum das mir das Tool das bauen abnimmt, da ich dabei die debian/rules anpassen muss, oder aber patches einspielen (und evtl. anpassen) ist das sowieso Handarbeit. Es geht nur darum, dass ich das fertige Zeug irgendwo hinwerfe und ein apt-get update machen muss. Das kann debpool und debarchiver wohl auch. Um etwas programmieren, sei es sh, perl oder python, wirst du fuer aufwendigere Sachen wohl kaum herumkommen. Wie schon angedeutet: Das Programmieren an sich ist weniger das Problem, eher die Sprache. Ich kann zwar Perl lesen und sh auch ein bisschen schreiben, aber in Python bin ich deutlich fitter... reprepro ist in C geschrieben, Isch kann auch ein bisschen C ;-) Aber mir ist Python bei solchen Dingen lieber, weil ich da doch weniger Code brauche... Andreas -- Good day to let down old friends who need help. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Eigenes deb-repository managen
Hi, ich bin momentan auf der Suche nach Alternativen zu debpool zum managen eines eigenen Repositories, weil obiges keine binary-only-uploads ohne zugehoeriges Source-Paket zulaesst und keine Pakete entfernen kann. Da apt-cache search je nach Suchwort-Wahl sehr verschiedene Listen zurueckliefert in denen teilweise die Tools die ich kenne nicht vorkommen mal meine Frage an alle: Was benutzt ihr so oder kennt ihr so das zum Managen eines privaten Repositories taugt. Notwendige Dinge sind - pool-Struktur wie auf den Debian-Servern - automatisch neue Pakete aus einem Verzeichnis aufnehmen (entweder als daemon oder durch Aufruf mittels cron), so dass ich neue Pakete nur in das Verzeichnis legen muss und nach einiger Zeit sind die Paketlisten aktualisiert - Entfernen von Paketen einfach moeglich - Unterstuetzung fuer sid+experimental - ausfuehrliche Fehlermeldungen wenn Pakete nicht passen (z.B. ein deb vergessen) und Pakete werden nicht geloescht sondern nur in ein rejected Verzeichnis bewegt - Signieren der Release-Dateien Das waers glaub ich fuers erste. Was ich bereits gefunden und wieder gestrichen habe: debarchiver - nur potato-struktur mini-dinstall - Keine ordentliche pool/dist-Struktur reprepro - zu wenig Doku, nur manuelles installieren von Paketen moeglich dak - wahrscheinlich kann das alles obige, aber ist vmtl. auch ein wenig mit Kanonen auf Spatzen geschossen Gibts noch mehr? Wenn ich nichts finde werde ich wohl debpool in Python neu schreiben und die fehlenden Features ergaenzen (Perl ist nich so mein Ding ;-) Andreas -- Reply hazy, ask again later. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenes deb-repository managen
On Fri, 12 May 2006 13:59:46 +0200 Andreas Pakulat [EMAIL PROTECTED] wrote: Hi, ich bin momentan auf der Suche nach Alternativen zu debpool zum managen eines eigenen Repositories, weil obiges keine binary-only-uploads ohne zugehoeriges Source-Paket zulaesst und keine Pakete entfernen kann. Du willst evtl apt-ftparchive und debarchiver wie hier: http://66.102.9.104/search?q=cache:ORrumsN2h18J:debian.cihar.com/howto.php+debian.cihar.com+howtohl=enct=clnkcd=1 (Leider hat Michal wohl die original Seite entfernt :() Andreas Evgeni -- ^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED]) d(O_o)b | PGP-Key-ID: 0xAC15B50C -|- | WWW: http://www.die-welt.net ICQ: 54116744 / \| IRC: #sod @ irc.german-freakz.net Frueher nahmen wir pr0n, um die Leitung vollzumachen. Heute tun's auch KDE-updates (jjFux - IRCNet) pgpEIDFNdfGJG.pgp Description: PGP signature
Re: Eigenes deb-repository managen
Am Freitag, den 12.05.2006, 13:59 +0200 schrieb Andreas Pakulat: ich bin momentan auf der Suche nach Alternativen zu debpool zum managen eines eigenen Repositories, weil obiges keine binary-only-uploads ohne zugehoeriges Source-Paket zulaesst und keine Pakete entfernen kann. Da apt-cache search je nach Suchwort-Wahl sehr verschiedene Listen zurueckliefert http://wiki.debian.org/HowToSetupADebianRepository in denen teilweise die Tools die ich kenne nicht vorkommen mal meine Frage an alle: Was benutzt ihr so oder kennt ihr so das zum Managen eines privaten Repositories taugt. debarchiver (online unter debian.wgdd.de/debian) Notwendige Dinge sind - pool-Struktur wie auf den Debian-Servern Warum ist das notwendig? - automatisch neue Pakete aus einem Verzeichnis aufnehmen (entweder als daemon oder durch Aufruf mittels cron), Lokal oder Remote? Für letzteres gibt es AFAIK für reprepro ein Skript. Ich weiß aber nicht, ob das schon im Paket ist. so dass ich neue Pakete nur in das Verzeichnis legen muss und nach einiger Zeit sind die Paketlisten aktualisiert - Entfernen von Paketen einfach moeglich reprepro oder dak Für debarchiver mach ich das händisch. - Unterstuetzung fuer sid+experimental Was soll daran problematisch sein? - ausfuehrliche Fehlermeldungen wenn Pakete nicht passen (z.B. ein deb vergessen) und Pakete werden nicht geloescht sondern nur in ein rejected Verzeichnis bewegt Oh Gott. Ich glaube, da hat nur dak viele Meldungen. Für debarchiver ist das angedacht, aber es fehlt an Schreibern. Bei reprepro kann ich keine Aussage machen. - Signieren der Release-Dateien Kann so ziemlich jedes aktuelle Programm, außer AFAIK mini-dinstall. Das waers glaub ich fuers erste. Was ich bereits gefunden und wieder gestrichen habe: debarchiver - nur potato-struktur Ja, und? Dafür braucht es keine Datenbank und das Repository wird trotzdem von allen existierenden Debian-Releases gelesen. Lokal-Patriotrismus mal beiseite - ich finde debarchiver momentan als beste Lösung. Pool-Struktur wäre schön, sicher, aber dass es keine gibt stört (zumindest mich) auch nicht weiter. Wenn sich jemand findet, der die Pool-Struktur mal implementiert, wäre das schön. Vom Prinzip würden sich debpool und debarchiver sehr gut ergänzen - von debpool noch die Pool-Struktur und die Unabhängigkiet von dpkg-scan* und apt-ftparchive implementiert und schon wäre es (IMHO nahezu) perfekt. Die Incoming-Mechanismen sind bisher am besten (ich nutze es lokal und remote). mini-dinstall - Keine ordentliche pool/dist-Struktur reprepro - zu wenig Doku, nur manuelles installieren von Paketen moeglich Nein. Dafür soll es ein Skript geben (hat mir jamnd vor gar nicht langer Zeit auf IIRC debian-mentors gesagt). dak - wahrscheinlich kann das alles obige, aber ist vmtl. auch ein wenig mit Kanonen auf Spatzen geschossen Tja. Das war es dann wohl. Weil: Mehr gibt es (aktuell) nicht. Gibts noch mehr? Nein. Du kannst dir natürlich deine eigene Lösung schreiben - wäre ja nicht das erste mal in der OSS-Szene :) - und hoppla Wenn ich nichts finde werde ich wohl debpool in Python neu schreiben da steht es ja auch. und die fehlenden Features ergaenzen (Perl ist nich so mein Ding ;-) Wenn ich dich dazu überreden könnte, eher die fehlenden Features in Perl in debarchiver zu ergänzen, würde ich sogar meine Mithilfe anbieten (Alioth-Projekt?). MfG Daniel
Re: Eigenes deb-repository managen
Andreas Pakulat wrote: ich bin momentan auf der Suche nach Alternativen zu debpool zum managen eines eigenen Repositories, weil obiges keine binary-only-uploads ohne zugehoeriges Source-Paket zulaesst und keine Pakete entfernen kann. [...] Was ich bereits gefunden und wieder gestrichen habe: reprepro - zu wenig Doku, nur manuelles installieren von Paketen moeglich Zugegeben, die doku ist vielleicht etwas mager, aber es tut seinen Zweck ziemlich gut. Es kann sowohl auf .changes files arbeiten, als auch auf .debs, oder .dsc's. Es kommt mit pool struktur, die es sicher trennt. Es macht allerdings wirklich nur Archiv Verwaltung, es kennt kein Konzept von 'Queues' (wie incoming, NEW, etc.). Diese Teile muesste man sich dann selber zusammenstricken, was es flexibel einsetzbar macht. dak - wahrscheinlich kann das alles obige, aber ist vmtl. auch ein wenig mit Kanonen auf Spatzen geschossen dak scheint mir wirklich Spitze in der Implementierung von Queues zu sein. Es ist aber auf die Ablaeufe von grossen Repositories wie ftp.debian.org optimiert. Gibts noch mehr? Wenn ich nichts finde werde ich wohl debpool in Python neu schreiben und die fehlenden Features ergaenzen (Perl ist nich so mein Ding ;-) Du solltest dir erst ueberlegen wie dein workflow wirklich ist, und was du wirklich brauchst. Um etwas programmieren, sei es sh, perl oder python, wirst du fuer aufwendigere Sachen wohl kaum herumkommen. Greetings, Reinhard -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenes deb-repository managen
On 12.05.06 14:16:40, Daniel Leidert wrote: Am Freitag, den 12.05.2006, 13:59 +0200 schrieb Andreas Pakulat: ich bin momentan auf der Suche nach Alternativen zu debpool zum managen eines eigenen Repositories, weil obiges keine binary-only-uploads ohne zugehoeriges Source-Paket zulaesst und keine Pakete entfernen kann. Da apt-cache search je nach Suchwort-Wahl sehr verschiedene Listen zurueckliefert http://wiki.debian.org/HowToSetupADebianRepository Sieht danach aus als ob das ein debarchiver Nutzer geschrieben hat ;-) Notwendige Dinge sind - pool-Struktur wie auf den Debian-Servern Warum ist das notwendig? Weil ich gerne Ordnung halte, jedenfalls aufm Rechner. - automatisch neue Pakete aus einem Verzeichnis aufnehmen (entweder als daemon oder durch Aufruf mittels cron), Lokal oder Remote? Für letzteres gibt es AFAIK für reprepro ein Skript. Ich weiß aber nicht, ob das schon im Paket ist. Da sich das ganze fuers erste aufm Laptop abspielt: lokal. Allerdings soll das Repository irgendwann mal auf meinen Server wandern und dann muss ich von aussen Pakete einfuegen koennen, per dput z.B. so dass ich neue Pakete nur in das Verzeichnis legen muss und nach einiger Zeit sind die Paketlisten aktualisiert - Entfernen von Paketen einfach moeglich reprepro oder dak Für debarchiver mach ich das händisch. Soll heissen debarchiver laesst alte Versionen im Repository wenn neuere reinkommen? Nee, das will ich definitiv nicht. Was ich meinte war dass ich Pakete ganz aus dem Repos entfernen kann wenn ich sie nicht mehr brauche. Mit debpool geht das momentan nicht, wenn ich da die debs loesche meckert er bei jedem Aufruf. Man kann sich aber recht leicht die GNU dbm's mit nem Python-Skript vornehmen und die Eintraege daraus entfernen. Genau diese 2 Schritte soll mir das Tool abnehmen, also entweder automatisch merken dass die Pakete weg sind und entsprechend aus der Datenbasis+Paketliste entfernen, oder aber dass ich ihm mit ner speziellen Option sage: Entferne Paket X. - Unterstuetzung fuer sid+experimental Was soll daran problematisch sein? Hmm, also reprepro sah mir irgendwie nicht danach aus als ob es das auf die Reihe bekommen wuerde, aber ich habs zugegebenermassen nicht ausgetestet... - ausfuehrliche Fehlermeldungen wenn Pakete nicht passen (z.B. ein deb vergessen) und Pakete werden nicht geloescht sondern nur in ein rejected Verzeichnis bewegt Oh Gott. Ich glaube, da hat nur dak viele Meldungen. Naja, debpool sagt mir halt wenn es ein Paket nicht einpflegen kann was ihm da gefehlt hat. Sowas meinte ich, nicht einfach nur das Paket verwerfen... Für debarchiver ist das angedacht, aber es fehlt an Schreibern. Ich glaub debpool fehlt es auch an Schreibern, das ist immernoch in experimental... Das waers glaub ich fuers erste. Was ich bereits gefunden und wieder gestrichen habe: debarchiver - nur potato-struktur Ja, und? Dafür braucht es keine Datenbank debpool braucht auch keine Datenbank, ausser du nennst gdbm ne Datenbank. Das ist IMHO aber eher ein serialisiertes Dictionary. Lokal-Patriotrismus mal beiseite - ich finde debarchiver momentan als beste Lösung. Pool-Struktur wäre schön, sicher, aber dass es keine gibt stört (zumindest mich) auch nicht weiter. Mich schon. (IMHO nahezu) perfekt. Die Incoming-Mechanismen sind bisher am besten (ich nutze es lokal und remote). Kannst du mir mal (gerne per PM) sagen wie das im Unterschied zu debpool funktioniert bei debarchiver? Bei debpool packe ich die dsc, changes, debs, diff.gz und source.tar.gz in ein Verzeichnis und debpool uebernimmt das dann. Was fehlt ist eine Mail mit dem Ergebnis zu verschicken. Wenn das incoming-Verzeichnis von remote-aus zugreifbar ist, also per ssh, FTP, HTTP-Put oder sonstwie kann man das Repository auch remote ablegen... und die fehlenden Features ergaenzen (Perl ist nich so mein Ding ;-) Wenn ich dich dazu überreden könnte, eher die fehlenden Features in Perl in debarchiver zu ergänzen, würde ich sogar meine Mithilfe anbieten (Alioth-Projekt?). Also meine Perl-Kenntnisse reichen gerade soweit das ich einfachen Perl-Code verstehen kann. Von daher: Leider nein, ich will Perl auch nicht wirklich lernen, mir gefaellt die Sprache einfach nicht... BTW: Ich fand bei den Recherchen grade heraus das debpool sehr wohl binary-only uploads unterstuetzt... Werde ich also mal schauen was ich mit debpool so anstellen kann. Wenn ichs mir genau ueberlege sollte es kein zu grosses Problem sein fuers erste die --rebuild-db-Funktion mit Leben zu erfuellen und damit dann das Entfernen von Paketen zu erlauben... Andreas -- You will be successful in love. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenes deb-repository managen
Am Freitag, den 12.05.2006, 15:10 +0200 schrieb Andreas Pakulat: On 12.05.06 14:16:40, Daniel Leidert wrote: Am Freitag, den 12.05.2006, 13:59 +0200 schrieb Andreas Pakulat: [..] http://wiki.debian.org/HowToSetupADebianRepository Sieht danach aus als ob das ein debarchiver Nutzer geschrieben hat ;-) Nein, nicht wirklich :) Selbst der Hinweis auf mein Howto stammt nicht von mir selbst - über den bin ich aber auf die Seite gekommen :) [..] so dass ich neue Pakete nur in das Verzeichnis legen muss und nach einiger Zeit sind die Paketlisten aktualisiert - Entfernen von Paketen einfach moeglich reprepro oder dak Für debarchiver mach ich das händisch. Soll heissen debarchiver laesst alte Versionen im Repository wenn neuere reinkommen? Nein, soll es nicht und macht debarchiver auch nicht. Du sprachst von Entfernen. Also wenn du ein Paket _komplett_ entfernen willst, benötigst du Zugriff auf das Dateisystem. Im gegensatz zu reprepro kennt debarchiver keine Kommandos, um ein Paket aus dem Repository und override(.src) zu löschen. Bei Updates eines Pakets im Repository werden die alten dateien mit Ausnahme der .orig.tar.gz gelöscht. Nee, das will ich definitiv nicht. Was ich meinte war dass ich Pakete ganz aus dem Repos entfernen kann wenn ich sie nicht mehr brauche. Darauf bezog ich mich. Mit debpool geht das momentan nicht, wenn ich da die debs loesche meckert er bei jedem Aufruf. Bei debarchiver lässt man das Programm danach einfach noch einmal mit der Option --scanall laufen und die ganzen Index-Dateien werden neu erstellt. Hatte debpool das nicht? Würde mich wundern. Man kann sich aber recht leicht die GNU dbm's mit nem Python-Skript vornehmen und die Eintraege daraus entfernen. Genau diese 2 Schritte soll mir das Tool abnehmen, also entweder automatisch merken dass die Pakete weg sind und entsprechend aus der Datenbasis+Paketliste entfernen, oder aber dass ich ihm mit ner speziellen Option sage: Entferne Paket X. Ersteres handhabe ich eben über genannte Option (ich habe ja Zugriff auf den Server) und ein Cron-Skript. Letzteres kenne ich von reprepro, kann aber nur lokal eingesetzt werden. - Unterstuetzung fuer sid+experimental Was soll daran problematisch sein? Hmm, also reprepro sah mir irgendwie nicht danach aus als ob es das auf die Reihe bekommen wuerde, aber ich habs zugegebenermassen nicht ausgetestet... Glaube ich nicht, dass reprepro damit Probleme hätte. Und falls doch, Bernhard Link ist sehr aktiv (IIRC das aktivste oder 2.-aktivste Projekt auf Alioth) und man kann ihn eigentlich immer erreichen (mein persönlicher Eindruck). - ausfuehrliche Fehlermeldungen wenn Pakete nicht passen (z.B. ein deb vergessen) und Pakete werden nicht geloescht sondern nur in ein rejected Verzeichnis bewegt Oh Gott. Ich glaube, da hat nur dak viele Meldungen. Naja, debpool sagt mir halt wenn es ein Paket nicht einpflegen kann was ihm da gefehlt hat. Sowas meinte ich, nicht einfach nur das Paket verwerfen... Ist in debarchiver rudimentär vorhanden und ließe sich auch erweitern (ist auch angedacht). Es fehlt nur an einer Person, die diesen Part erweitert. Meine reprepro-Erfahrungen beziehen sich auf längst vergangene Zeiten, so dass ich darüber nichts sagen kann. Für debarchiver ist das angedacht, aber es fehlt an Schreibern. Ich glaub debpool fehlt es auch an Schreibern, das ist immernoch in experimental... Arbeitet Joel überhaupt noch an debpool? Ich dächte, ich habe ihn schon hin- und wieder mal bei Diskussionen um debarchiver im CC gesehen. Könnte mich da allerdings auch irren. Das waers glaub ich fuers erste. Was ich bereits gefunden und wieder gestrichen habe: debarchiver - nur potato-struktur Ja, und? Dafür braucht es keine Datenbank debpool braucht auch keine Datenbank, ausser du nennst gdbm ne Datenbank. Das ist IMHO aber eher ein serialisiertes Dictionary. Hmm. Ja, sicher kein Monster wie MySQL oder PostgreSQL. [..] (IMHO nahezu) perfekt. Die Incoming-Mechanismen sind bisher am besten (ich nutze es lokal und remote). Kannst du mir mal (gerne per PM) sagen wie das im Unterschied zu debpool funktioniert bei debarchiver? http://debian.wgdd.de/howto/howto-aptrep#aptrep_custom_dput Also es gibt mehrere Möglichkeiten: Es gibt ein generelles incoming/ Verzeichnis, aus dem nur Pakete mit einer .changes-Datei einsortiert werden können. Entscheidend ist hier, was im 'Distribution:'-Feld der .changes-Datei steht. Alternativ können Pakete mit und ohne .changes Datei in festgelegte (zugeordnete) Verzeichnisse einsortiert werden, z.B. incoming/sarge, incoming/sid ... Pakete, die in diesen Verzeichnissen landen, werden dann in den spezifizierten Zweig sortiert. Das ist aktuell auch ein Workaround, um ein Paket zu verschieben. Die Verzeichnisse werden per Cron-Job kontrolliert. Bei debpool packe ich die dsc, changes, debs, diff.gz und source.tar.gz in ein Verzeichnis und debpool
Re: Eigenes deb-repository managen
On 12.05.06 15:48:39, Daniel Leidert wrote: Am Freitag, den 12.05.2006, 15:10 +0200 schrieb Andreas Pakulat: On 12.05.06 14:16:40, Daniel Leidert wrote: Am Freitag, den 12.05.2006, 13:59 +0200 schrieb Andreas Pakulat: Mit debpool geht das momentan nicht, wenn ich da die debs loesche meckert er bei jedem Aufruf. Bei debarchiver lässt man das Programm danach einfach noch einmal mit der Option --scanall laufen und die ganzen Index-Dateien werden neu erstellt. Hatte debpool das nicht? Würde mich wundern. Nun debpool kennt die 3 Optionen: rebuild-files - erzeugt die .package und .source Dateien neu rebuild-dbs - erzeugt neue gdbm-DB's rebuild-all - fuehrt die obigen 2 aus Das Problem ist: rebuild-dbs tut genau gar nichts. Deswegen meckert debpool bei jedem nachfolgenden Lauf das da ein Paket fehlt... Nicht weiter schlimm, aber schoen auch nicht... - Unterstuetzung fuer sid+experimental Was soll daran problematisch sein? Hmm, also reprepro sah mir irgendwie nicht danach aus als ob es das auf die Reihe bekommen wuerde, aber ich habs zugegebenermassen nicht ausgetestet... Glaube ich nicht, dass reprepro damit Probleme hätte. Und falls doch, Bernhard Link ist sehr aktiv (IIRC das aktivste oder 2.-aktivste Projekt auf Alioth) und man kann ihn eigentlich immer erreichen (mein persönlicher Eindruck). Genau das ist mein Problem mit debpool, da gabs seit 12 Monaten keine neue Version, ich denke der Maintainer ist MIA, da er das Paket ja auch nicht aufgegeben hat... Für debarchiver ist das angedacht, aber es fehlt an Schreibern. Ich glaub debpool fehlt es auch an Schreibern, das ist immernoch in experimental... Arbeitet Joel überhaupt noch an debpool? Ich dächte, ich habe ihn schon hin- und wieder mal bei Diskussionen um debarchiver im CC gesehen. Könnte mich da allerdings auch irren. Ich denke nicht, genau da liegt wahrscheinlich das Problem. Nunja, werde ich mir also erstmal den Quellcode von debarchiver ansehen und schauen ob ich da helfen kann. Wenn nicht kann ich immernoch ne Python-Implementierung versuchen... Das waers glaub ich fuers erste. Was ich bereits gefunden und wieder gestrichen habe: debarchiver - nur potato-struktur Ja, und? Dafür braucht es keine Datenbank debpool braucht auch keine Datenbank, ausser du nennst gdbm ne Datenbank. Das ist IMHO aber eher ein serialisiertes Dictionary. Hmm. Ja, sicher kein Monster wie MySQL oder PostgreSQL. gdbm ist keine Datenbank, auch wenn es der Name vermuten laesst. Das ist nichts weiter als eine key-value Zuordnung mit schnellen Suchalgorithmen. Ich kenne ja Berkley DB nicht, aber ich denke die und auch SQLite sind eher DB's bzw. DBMS' als gdbm. Bei debpool packe ich die dsc, changes, debs, diff.gz und source.tar.gz in ein Verzeichnis und debpool uebernimmt das dann. debpool war da ähnlich, kann aber nicht so granular damit umgehen, wohin ein Paket sortiert werden soll und es konnte, du hast es IMO genannt, auch nicht mit einen Binary-only-Paketen umgehen. Siehe mein BTW weiter unten, debpool kann das schon wenn man ihm erlaubt Pakete mit derselben Versionsnummer zu installieren die schon im pool enthalten ist. Im Abschnitt 2.2 des Howtos, bin ich auch auf die Unterschiede zwischen den verschiedenen Lösungen eingegangen. Hmm, was mir da grad einfaellt: Wieso ist die Loesung ohne apt-ftparchive besser als mit? Wegen der zusaetzlichen Dependecy die wegfallen wuerde? Warum kopiert ihr nicht einfach den entsprechenden Teil aus debpool ;-) [..] BTW: Ich fand bei den Recherchen grade heraus das debpool sehr wohl binary-only uploads unterstuetzt... Werde ich also mal schauen was ich mit debpool so anstellen kann. Wenn ichs mir genau ueberlege sollte es kein zu grosses Problem sein fuers erste die --rebuild-db-Funktion mit Leben zu erfuellen und damit dann das Entfernen von Paketen zu erlauben... Gib Bescheid, wenn du debpool die Schwächen ausgemerzt hast. Vielleicht wechsle ich dann ;) s.o. Ich hab nach dem Abschicken gesehen das die aktuelle experimental Version noch aus pre-Sarge-Zeiten stammt. Ich denke ich werde erstmal debarchiver Source ziehen und schauen ob ich durchblicke. Wenn ich da pool-Support hinbekommen habe duerfte das fuer mich (fast) schon ausreichend sein... Andreas -- You feel a whole lot more like you do now than you did when you used to. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenes deb-repository managen
On 12.05.06 12:58:31, Reinhard Tartler wrote: Andreas Pakulat wrote: ich bin momentan auf der Suche nach Alternativen zu debpool zum managen eines eigenen Repositories, weil obiges keine binary-only-uploads ohne zugehoeriges Source-Paket zulaesst und keine Pakete entfernen kann. [...] Was ich bereits gefunden und wieder gestrichen habe: reprepro - zu wenig Doku, nur manuelles installieren von Paketen moeglich Zugegeben, die doku ist vielleicht etwas mager, aber es tut seinen Zweck ziemlich gut. Es kann sowohl auf .changes files arbeiten, als auch auf .debs, oder .dsc's. Es kommt mit pool struktur, die es sicher trennt. Es macht allerdings wirklich nur Archiv Verwaltung, es kennt kein Konzept von 'Queues' (wie incoming, NEW, etc.). Diese Teile muesste man sich dann selber zusammenstricken, was es flexibel einsetzbar macht. Grade sowas wie incoming brauch ich aber, NEW nicht so sehr, weil es vor allem darum geht das ich haeufiger mal offizielle Debian-Pakete selbst neu baue (mit anderen Optionen) bzw. auch eigene Programme ueber Pakete installiere. Und da es dafuer schon fertige Loesungen gibt ist halt reprepro aussen vor, weil es da fehlt... Gibts noch mehr? Wenn ich nichts finde werde ich wohl debpool in Python neu schreiben und die fehlenden Features ergaenzen (Perl ist nich so mein Ding ;-) Du solltest dir erst ueberlegen wie dein workflow wirklich ist, und was du wirklich brauchst. Das hatte ich eigentlich schon geschrieben: Ich baue ein Paket (entweder ein rebuild eines Paketes, ein eigenes Paket oder letztens hab ich fuer jmd. gnucash auf i386 gebaut und musste dafuer erst noch aqbanking bauen und dem chroot verfuegbar machen), lade es irgendwo ab und ein paar Minuten/Stunden spaeter hab ich entweder ne Mail ueber den Miserfolg oder kann ein aptitude update machen und das Paket installieren. Irgendwann gibts dann vllt. eine neue Version aus den Debian-Repos und ich brauche meine eigene Version nicht mehr und moechte das gesamte Paket endgueltig loeschen. Oder aber ich baue eine neue Version des Pakets, lade die hoch und krieg wieder ne Mail... Um etwas programmieren, sei es sh, perl oder python, wirst du fuer aufwendigere Sachen wohl kaum herumkommen. Wie schon angedeutet: Das Programmieren an sich ist weniger das Problem, eher die Sprache. Ich kann zwar Perl lesen und sh auch ein bisschen schreiben, aber in Python bin ich deutlich fitter... Andreas -- It's lucky you're going so slowly, because you're going in the wrong direction. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
