Linuxtag Idee: Fedora Package

Ideen und Vorschläge sind willkommen.

Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Di Jun 30, 2009 1:59 pm

Der Fedora Package Verantwortliche kam zu unserem Stand und sagte er hätte gerne ein YaCy-Package, das wie ich verstanden habe folgende Kriterien erfüllen muss:
- es darf keine eigene Libraries mitbringen
- es darf keine Files im Applikationsverzeichnis generieren.
- (ggf. mehr Kriterien, mehr habe ich nicht mitbekommen und flori weiss mehr darüber).

Für den ersten Punkt würde ich nun die lib und libx zusammenlegen wollen. Dann sind alle auf einem Platz. Für den 2. Punkt haben wir ein symbolic Link fürs DATA vereinbart. Auf unserer Seite hat für die Kommunikation mit Fedora flori den Hut auf.

Arbeitspunkte:

- ein Wunsch an alle:
bitte gucken, ob alle unsere libs noch aktuell sind, und ggf. eine Lib durch eine neuere ersetzen.

- ich mache die Zusammenlegung von lib und libx

- flori: kommunikation mit Fedora, der Packager dort wollte den Rest machen (ist das richtig flori?)
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon Lotus » Mi Jul 01, 2009 12:05 pm

Inwieweit darf eigentlich die YaCy-interne Update-Funktion einem Paketmanagement dazwischenfunken?
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 01, 2009 12:15 pm

gute Frage, das würde ja heissen, dass wir keinen Updater drin haben dürfen was ich für einen fürchterlichen Käse halten würde. Das kann nur der Packager von Fedora beantworten. Florian, hast du den Kontakt noch offen? Wenn nicht, schreibe dem bitte mal eine Email. Der ist ja immerhin von sich aus auf uns zugekommen, das ist eine wirklich gute Chance mal endlich ein Package in einem Linux-Derivat zu haben.
Die Konsolidierung von lib und libx habe ich ja gestern schon gemacht, fehlt eigentlich nur dass der packager nach der Installation ein symbolic Link für unser DATA setzt.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon flori » Mi Jul 01, 2009 3:20 pm

Ich hab schon mit ihm gemailt, ich hab bloß diese Woche kaum mehr kein Zeit als Mail zu beantworten.
Das mit dem Updater ist in der Tat ein Problem. Man muss eine Option ins Buildskript einbauen, die den Updater vollständig deaktiviert. Dies ist aber nicht schlimm, weil das Update über die Distribution sowieso zuverlässiger ist.
Das mit dem Symlink ist übrigends schon eingebaut. lib und libx musste man eigentlich nicht wegen dem Packeten zusammenfassen, schadet aber nichts. Viel wichtiger wäre ein Release ohne class und jars. Dazu werde ich noch ein ant-target schreiben.
flori
 
Beiträge: 245
Registriert: Mi Jun 27, 2007 10:17 pm
Wohnort: Karlsruhe

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 01, 2009 3:30 pm

Orbiter hat geschrieben:Der Fedora Package Verantwortliche

Naja *der* Verantwortliche bin ich nicht (das waere Tom Callaway) aber einer von vielen - vor allem mit Interesse an YaCy :)

Orbiter hat geschrieben: kam zu unserem Stand und sagte er hätte gerne ein YaCy-Package, das wie ich verstanden habe folgende Kriterien erfüllen muss:
- es darf keine eigene Libraries mitbringen
- es darf keine Files im Applikationsverzeichnis generieren.
- (ggf. mehr Kriterien, mehr habe ich nicht mitbekommen und flori weiss mehr darüber).


Das liesse sich uebrigens auch hier nachvollziehen:
http://fedoraproject.org/wiki/Packaging/Java
insb. "Pre-built JAR files / Other bundled software"

Edit/Addendum:
Wider meiner urspruenglichen Annahme ist es erlaubt, auf Jars von YaCy aus zu verlinken - das vereinfacht einiges. Ich bin bisher von den Mono-Richtlinien ausgegangen.

Ferner gilt immer - zusaetzlich - https://fedoraproject.org/wiki/Packaging/Guidelines

Sprich: Pakete in Fedora muessen immer hohe Qualitaetsstandards erfullen (A Good Thing (tm))

Orbiter hat geschrieben:Für den ersten Punkt würde ich nun die lib und libx zusammenlegen wollen. Dann sind alle auf einem Platz. Für den 2. Punkt haben wir ein symbolic Link fürs DATA vereinbart. Auf unserer Seite hat für die Kommunikation mit Fedora flori den Hut auf.

Arbeitspunkte:

- ein Wunsch an alle:
bitte gucken, ob alle unsere libs noch aktuell sind, und ggf. eine Lib durch eine neuere ersetzen.

- ich mache die Zusammenlegung von lib und libx

- flori: kommunikation mit Fedora, der Packager dort wollte den Rest machen (ist das richtig flori?)


Lotus hat geschrieben:Inwieweit darf eigentlich die YaCy-interne Update-Funktion einem Paketmanagement dazwischenfunken?


Eigentlich gar nicht. Sobald Dateien am Paketmanagement "vorbeigeaendert" werden, hat dies u.a.
- fehlerhafte Pruefsummen
- "Orphans" (verwaiste Dateien)
- Clashes beim naechsten regulaeren Update
zur Folge.

Ausnahme waere, wie es bei Elisa (jetzt Moovida) gemacht wurde:
Ein spezieller User mit eigenem $HOME kann die applikationsinterne Updatefunktionaelitaet benutzen, neue/geaenderte Dateien wandern in diesem Moment nur in das $HOME und haben automatisch Praezedenz ueber die des Paketsystems. Nur, dies muss die Anwendung hergeben koennen; ferner wird es dann mit Selinux-aktivierten Systemen schwierig (standardmaessig aktiviert in Fedora), ein Showstopper.

Deshalb ist es umso wichtiger, dass ich sog. Co-Maintainer finde, damit haeufiges Updaten des RPM moeglich wird; ferner haben "wir" (Fedora) FEver, ein Tool, welches regelmaessig auf Upstream-Updates prueft per HTTP und Regexps.

Meine naechsten Schritte sind:
- Minimal funktionsfaehiges SPECfile bauen
- Auf Vorhandensein der mitgelieferten, "verbotenen" Drittprojekt-Jarfiles als Fedora-RPMs pruefen
- Florians geleistete Vorarbeit der M4-Makrodatei fuer das SysV-Initskript evtl. ausbauen, um im Endeffekt GNU automake zu verwenden fuer alle distrospezifischen Dateien

Unbedingt wichtig von Eurer Seite: Kooperativitaet (gegeben, denke ich!) und Geduld - habe einen Vollzeitjob nebenbei ;)
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 01, 2009 3:57 pm

Hallo e-user, prima dass du hier in unseren Fedora-Topic eingestiegen bist!
Ich picke mir jetzt einfach mal nur eine Sache raus, an der ich dann arbeite:

e-user hat geschrieben:
Lotus hat geschrieben:Inwieweit darf eigentlich die YaCy-interne Update-Funktion einem Paketmanagement dazwischenfunken?


Eigentlich gar nicht. Sobald Dateien am Paketmanagement "vorbeigeaendert" werden, hat dies u.a.
- fehlerhafte Pruefsummen
- "Orphans" (verwaiste Dateien)
- Clashes beim naechsten regulaeren Update
zur Folge.

Dann muss das Updaten eben abgeschaltet werden. Wir haben im Auto-Updater Servlet tatsächlich schon eine Update-Sperre drin, und zwar greift die wenn man mit einem Entwicklerrelease, das nicht per ant gebildet wurde gestartet hat, sondern eins das im Eclipse gestartet wurde. Damit wollte ich verhindern dass man sich versehentlich die eigenen Codeänderungen zerschiesst. Die Sperre sollte nicht nur beim Aufrufen des Servlet sondern auch bei der auto-Update Funktion greifen. Insofern ist das eine gute Methodik, um auch Releases in die Sperre mit einzubeziehen, die aufgrund des Packaging das nicht wollen. Ich würde diesen Vorgang so gut wie es geht transparent machen wollen, und zwar so:
- das Update-Servlet bleibt drin, aber erklärt ggf. die Sperre
- wenn man aus nun einem der beiden möglichen Fällen nicht updaten darf (Fedora-Release / Developer-Release), steht das dann in dem Servlet drin. Das erklärt damit auch dass die Funktion zwar da ist, aber in diesem Kontext nicht genutzt werden darf, weil es bessere Alternativen gibt (Fedora: Update; Developer: SVN-Update)
- die Sperre wird durch die Form des Release-namens gezogen, d.h. wir müssten vereinbaren, dass die Fedora-Packages einen bestimmten Namen haben und dieser löst dann die Sperre im Updater aus.

Damit ich hier die Änderung machen kann brauchen wir also sowas wie eine Namenskonvention für die Fedora-Releases.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon flori » Mi Jul 01, 2009 4:11 pm

Die Sache vom Releasenamen abhängig machen finde ich nicht gut. Den Releasenamen kann/muss man manchmal ändern.
Das ganze sollte entweder eine Buildoption oder eine Option in build.properties sein. Nach dem compilen ist das am besten fest verdrahtet, damit niemand nachträglich auf die Idee kommt, da was zu ändern. Am Wochenende würde ich mir das auch anschauen.
flori
 
Beiträge: 245
Registriert: Mi Jun 27, 2007 10:17 pm
Wohnort: Karlsruhe

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 01, 2009 4:32 pm

ok, wie du denkst dass es besser ist. Man muss das nur von Java aus lesen können.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon Lotus » Mi Jul 01, 2009 8:03 pm

Ganz primitiv: eine Sperr-Datei im Dateisystem anlegen und abfragen. Geht in einem Build-Target ja ziemlich einfach.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Fr Jul 03, 2009 9:15 am

Hier mal mein aktueller Stand.
Ich habe sozusagen ein Skelett angelegt, welches so weit wie momentan moeglich YaCy als Paket beschreibt und ferner alle Abhaengigkeiten gelistet, die ich gerne von Euch mitgeprueft haben moechte. Es laesst sich jetzt schon sagen: Es wird eine Menge Arbeit.

Hinter der URI - http://akahl.fedorapeople.org/yacy/ - findet Ihr eine org-mode-Datei mit den Abhaengigkeiten und die aktuelle Spec-Datei. Zur Zeit sind es 14 Abhaengigkeiten, die komplett neu als Paket erstellt und vier, die von JPackage nach Fedora gebracht werden muessen. Des Weiteren gibt es zwei JARs, bei denen ich mir nicht sicher bin, ob sie vom YaCy-Projekt kommen oder nicht, siehe Tabelle in der org-Datei.
Bei der Menge von - noch - fehlenden Abhaengigkeiten werde ich mir auf jeden Fall noch andere Maintainer suchen muessen, sonst klebt der Dauersupport fuer 18+ Abhaengigkeiten ebenfalls an mir. Einige der Abhaengigkeiten scheinen upstream eingeschlafen zu sein (2-3 Jahre keine Releases), an dieser Stelle lohnt es sich von Eurer Seite nachzudenken, ob Ihr sie forkt und zu YaCy-Klassen macht, da Ihr gegebenenfalls eh keine Bugfix-Resonanz upstream erhalten werdet. In der Praxis hiesse das: Sie muessen in das yacy.jar.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Fr Jul 03, 2009 9:33 am

flori, Lotus: bitte konkretisiert den Sperrmechanismus, dann baue ich das in den Updater ein.

e-user hat geschrieben:Ich habe sozusagen ein Skelett angelegt, welches so weit wie momentan moeglich YaCy als Paket beschreibt und ferner alle Abhaengigkeiten gelistet, die ich gerne von Euch mitgeprueft haben moechte. Es laesst sich jetzt schon sagen: Es wird eine Menge Arbeit.

ok super, du hast die Baustelle aufgemacht. In kleinen Schritten läßt sich auch eine Menge Arbeit leicht erledigen, vor allem wenn man sie aufteilt. Am schönsten wäre es, wenn so viele wie möglich 'hier' rufen wenn es was zu tun gibt.

e-user hat geschrieben:Hinter der URI - http://akahl.fedorapeople.org/yacy/ - findet Ihr eine org-mode-Datei mit den Abhaengigkeiten und die aktuelle Spec-Datei. Zur Zeit sind es 14 Abhaengigkeiten, die komplett neu als Paket erstellt und vier, die von JPackage nach Fedora gebracht werden muessen.

in
http://akahl.fedorapeople.org/yacy/yacy.org
http://akahl.fedorapeople.org/yacy/yacy.spec
müssten jetzt schon erste Korrekturen rein: ich habe ja lib und libx zusammengelegt, um das ganze zu vereinfachen. Also überall einfach libx durch lib ersetzen, dann stimmt es.

e-user hat geschrieben:Des Weiteren gibt es zwei JARs, bei denen ich mir nicht sicher bin, ob sie vom YaCy-Projekt kommen oder nicht, siehe Tabelle in der org-Datei.

das svnRevNr.jar wird während dem Build erzeugt und beinhaltet die Versionsnummer des Build, das dann während der Laufzeit zur Abfrage der Versionsnummer benutzt wird. Ich weiss nicht mehr wer sich das ausgedacht hat aber ich kann drauf verzichten wenn sich jemand was anderes ausdenkt.

das domaingraph.jar ist mit Hilfe von Processing erzeugt worden, dass ist die IDE aus processing.org, das Java Applets erzeugt. Die Sourcen liegen natürlich bei.

e-user hat geschrieben:Bei der Menge von - noch - fehlenden Abhaengigkeiten werde ich mir auf jeden Fall noch andere Maintainer suchen muessen, sonst klebt der Dauersupport fuer 18+ Abhaengigkeiten ebenfalls an mir. Einige der Abhaengigkeiten scheinen upstream eingeschlafen zu sein (2-3 Jahre keine Releases), an dieser Stelle lohnt es sich von Eurer Seite nachzudenken, ob Ihr sie forkt und zu YaCy-Klassen macht, da Ihr gegebenenfalls eh keine Bugfix-Resonanz upstream erhalten werdet. In der Praxis hiesse das: Sie muessen in das yacy.jar.

höhö, wir haben per default gar kein yacy.jar sondern Einzelklassen (in classes). Sollten wir vielleicht mal bauen, das ist ja kein Zauberwerk. Hat jemand einen Einwand oder Idee warum wir kein yacy.jar haben sondern Einzelklassen?
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon flori » Fr Jul 03, 2009 11:18 am

Orbiter hat geschrieben:flori, Lotus: bitte konkretisiert den Sperrmechanismus, dann baue ich das in den Updater ein.

Heut abend hab ich Zeit, da will ich das noch machen. Ich stell mir das so vor, wie die das auf http://stackoverflow.com/questions/1012 ... mpile-time empfehlen.

Orbiter hat geschrieben:höhö, wir haben per default gar kein yacy.jar sondern Einzelklassen (in classes). Sollten wir vielleicht mal bauen, das ist ja kein Zauberwerk. Hat jemand einen Einwand oder Idee warum wir kein yacy.jar haben sondern Einzelklassen?

Stimmt nicht ganz, es gibt ein jar-target was auch für die Debian/Fedora/...-Packete genutzt wird und funktioniert, man könnte überlegen, ob man das auch standardmäßig einschaltet.
flori
 
Beiträge: 245
Registriert: Mi Jun 27, 2007 10:17 pm
Wohnort: Karlsruhe

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Fr Jul 03, 2009 11:36 am

flori hat geschrieben:Stimmt nicht ganz, es gibt ein jar-target was auch für die Debian/Fedora/...-Packete genutzt wird und funktioniert, man könnte überlegen, ob man das auch standardmäßig einschaltet.

Von mir aus gerne. Also standardmäßig _keine_ Files mehr in <yacy>/classes erzeugen. Wenn du das umbauen könntest wäre das super.

Ausserdem: ich würde gerne die einzel- built.xml der Parser los werden. Das sollte doch jetzt gehen wo die standardmäßig drin sind. Kannst du das gleich auch mit umbauen?
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon Lotus » Sa Jul 04, 2009 1:40 pm

Jemand hat mal gefragt wieso das aktuelle Release ohne libx größer ist (finde ich nicht mehr). Es werden mehr libs mitgeliefert:
Code: Alles auswählen
activation.jar
commons-discovery.jar
gnumail.jar
inetlib.jar
J7Zip.License
jaxrpc.jar
jmimemagic-0.1.0.license
jrpm-SNAPSHOT.jar
wsdl4j.jar

Brauchen wir anscheinend alle nicht?
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mo Jul 06, 2009 9:05 am

Update!

Ich habe die Fedora-Pakete mittels Symlinks an Stelle der mitgelieferten JARs im aktuellen YaCy-Release (kein SVN) getestet. Bis auf jakarta-commons-fileupload, welches zu alt zu sein scheint (1.0 in Fedora), kann YaCy immer noch ordentlich starten. Jedoch bin ich mir nicht sicher, ob bestimmte JAR-Funktionalitaeten zum Testen erst "getriggert" werden muessen, vielleicht koennt Ihr mir hier ja helfen.

http://akahl.fedorapeople.org/yacy/yacy.org
.. enthaelt den aktuellen Stand der Dinge.

https://bugzilla.redhat.com/show_bug.cgi?id=509785
.. enthaelt meinen Bugreport mit Bitte um das jakarta-commons-fileupload-Update.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mo Jul 06, 2009 9:37 am

e-user hat geschrieben:Jedoch bin ich mir nicht sicher, ob bestimmte JAR-Funktionalitaeten zum Testen erst "getriggert" werden muessen, vielleicht koennt Ihr mir hier ja helfen.

Wir haben leider nicht alle Klassen aus den jars durch direkte Instantiierung der Objekte eingebunden, sondern manche über Reflection. So weit ich weiss betrifft das aber nur die Parser. Das heisst das man das notwendige Triggern über einen Parsertest machen kann. Dazu mache ich dann folgendes:
- Intranet-Indexing einschalten
- als repository-Pfad dann <yacy-home>test\parsertest\ einstellen, da sind ganz viele verschiedene Datenformate drin (aber wohl nicht vollständig, kann da nochmal jemand gucken was wir noch an Testdokumenten bauen können)
- einen Crawl starten, da dann einfach von dem default Pfad, der in das eingestellte repository geht.

Wenn das durchläuft wurden die per symlink verbundenen jars gezogen. Der Test ist aber nur vollständig, wenn die Testdateien bzgl. der jars vollständig sind. Ich setze mich aber auch mal dran und baue das Einbinden per reflection aus, das brauchen wir ja jetzt nicht mehr.

Lotus hat geschrieben:Jemand hat mal gefragt wieso das aktuelle Release ohne libx größer ist (finde ich nicht mehr). Es werden mehr libs mitgeliefert:
..
Brauchen wir anscheinend alle nicht?

Schwer zu sagen, kann man nur mit Bestimmtheit sagen wenn das Reflection-Laden raus ist und man die jars dann einzeln raus nehmen kann um zu sehen ob es built-errors gibt. Also noch ein Grund das Reflection auszubauen.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon flori » Sa Jul 11, 2009 12:36 pm

Also, ich hab nochmal mit e-user gesprochen. Es ist so, dass das Hauptproblem ist, dass wir 9 Projekte als Abhängigkeit haben, die nicht mehr gepflegt werden, wo das letzte Update schon mehrere Jahre zurückliegt.
Für einen Fedorapackager bedeutet das dann, das er für das Packet verantwortlich ist und Bugreports und ähnliches abarbeiten muss.
Aus den Packetrichtlinien:
Be wary of maintaining software with no upstream since all the burden of maintaining the codebase as well as packaging issues are with you.


Das kann man folgenderweise lösen:
1. Wir nehmen die Packete mit komplettem Source in unser SVN auf, sodass wir die Jars direkt bei uns bauen können. Dadurch können wir Bugs die uns betreffen selbst fixen, müssen uns aber nicht unbedingt um nicht YaCY-spezifische Dinge kümmern, wie es bei einem getrennten Federa nötig wäre.

2. Wir ersetzen alte Bibliotheken durch neuere, die gepflegt werden und idealerweise schon in Fedora oder anderen Distros vorhanden sind. Spontan sind mir dabei folgende eingefallen:
Tar: Ant kann auch tars lesen und erzeugen: http://svn.apache.org/viewvc/ant/core/t ... tools/tar/
ODF: Nach kurzer internetsuche bin ich auf http://www.jopendocument.org/ gestoßen
to be continued...
flori
 
Beiträge: 245
Registriert: Mi Jun 27, 2007 10:17 pm
Wohnort: Karlsruhe

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Sa Jul 11, 2009 11:05 pm

Spontan würde ich mal sagen dass Punkt 2 sowieso der richtige Weg ist, auch unabhängig von den Fedora-Bedingungen.
Punkt 1: brr, oh je, was da auf uns zukommt? Das können ja Massen von Code sein und nicht wenig Abhängigkeiten haben. Ich würde da vorschlagen: anderen Maintainer finden, der das übernimmt, vielleicht auch einen von uns?

Orbiter hat geschrieben:Ich setze mich aber auch mal dran und baue das Einbinden per reflection aus, das brauchen wir ja jetzt nicht mehr.

Das ist nun fertig mit SVN 6192
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mo Jul 13, 2009 8:53 am

Huhu,

habe nun auch das aktualisierte Org-FIle hochgeladen, siehe
http://akahl.fedorapeople.org/yacy/yacy.org

flori hat es schon ganz gut wiedergegeben, hier noch mal fuer Euch die jeweiligen Passi in Fedoras Packaging-Richtlinien:
http://fedoraproject.org/wiki/Packaging ... d_software
https://fedoraproject.org/wiki/PackageM ... Exceptions
"Dead Or Unresponsive Upstream Projects - (...) Be wary of maintaining software with no upstream since all the burden of maintaining the codebase as well as packaging issues are with you. If upstream is unresponsive and many distributions are deviating significantly, it might be a opportunity for a cross distribution fork (Similar to XFree86 and Xorg)."

Orbiter hat geschrieben:Punkt 1: brr, oh je, was da auf uns zukommt? Das können ja Massen von Code sein und nicht wenig Abhängigkeiten haben. Ich würde da vorschlagen: anderen Maintainer finden, der das übernimmt, vielleicht auch einen von uns?


Naja ich stehe in dem Falle gerne als Lehrer, Sponsor, Co-Maintainer etc. bereit!
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mo Jul 13, 2009 11:12 am

ich würde doch eher Option 2 sehen...

Ich bin mal durch die org-Datei gegangen und sehe hier folgende action items:

@e-user: bitte alle libx durch lib ersetzen! libx gibts nicht mehr, ist alles in lib.

./lib/tm-extractors-1.0.jar
ist raus geflogen, hat low012 ersetzt
@e-user: kann auch raus

./addon/jsmooth/lib/jsmoothgen-ant.jar
@Lotus: brauchst du das, um Windows-Builds zu machen? egal ob ja oder nein: Ist wohl nicht relevant für fedora und kann dort raus
@e-user: das muss nicht ins fedora

./lib/sbbi-upnplib-1.0.4.jar
@Lotus: kannst du mal gucken was wir damit machen? raus nehmen würde ich das nicht wollen. Ideen?

./libbuild/nsisant-1.2.jar
@flori: wer braucht das? der YaCy Source code nicht. du hast das vor einem Jahr eingebaut. Brauchen wir das noch?

./lib/jrpm-head.jar
Wird ersetzt durch jrpm-SNAPSHOT.jar. Habs entfernt, SVN 6202.
@e-user: kannst du raus nehmen.

./lib/jmimemagic-0.1.0.jar
schmeiss ich erst mal raus, sehe keine Verwendung dafür, obwohl es ein nettes Ding ist. Vielleicht können wir das mal in einer bereinigten Version als Source übernehmen.

./lib/odf_utils_05_11_29.jar
brauchen wir für Open Office Dokumente. Kann da mal einer gucken was sich machen läßt? Ersatz?

./lib/webcat-0.1-swf.jar
flash-Parser
@low012: was machen wir da?

./lib/tar.jar
das tar brauchen wir. Die Lizenz die wir hier haben sagt, das wäre 'Public Domain'. Nach einigem Suchen habe ich herausgefunden, dass das nun ein Teil von Apache Ant ist: http://ant.apache.org
Wenn man die Source-Distribution läd, sieht man dass die tar Sourcen da drin sind. Wir könnten dann unser tar durch das von apache ant ersetzen, aber das ist ziemlich fett und hat unheimlich viel Krempel drin. Vielleicht können wir auch einfach nur die Sourcen dort raus nehmen.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon Low012 » Mo Jul 13, 2009 11:41 am

Orbiter hat geschrieben:./lib/webcat-0.1-swf.jar
flash-Parser
@low012: was machen wir da?

Brrrr, der Flash-Parser! Ehrlich gesagt habe ich in der Suche noch nie ein Flash-Ergebnis bekommen, weshalb ich vermute, dass der Parser in den meisten Fällen keine verwertbaren Ergebnisse liefert. Wenn es an webcat hängt, dass YaCy nicht in Fedora kommen kann, wäre ich dafür den Parser komplett zu entfernen.

Leider kenn ich keine Library, die maintained wird, die wir stattdessen nutzen könnten. Nutch kann wohl auch Flash parsen, aber die benutzen auch eine Library, die nicht mehr weiterentwickelt wird: http://www.anotherbigidea.com/javaswf/
Low012
 
Beiträge: 2214
Registriert: Mi Jun 27, 2007 12:11 pm

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mo Jul 13, 2009 3:51 pm

Lotus hat geschrieben:Jemand hat mal gefragt wieso das aktuelle Release ohne libx größer ist (finde ich nicht mehr). Es werden mehr libs mitgeliefert:
Code: Alles auswählen
activation.jar
commons-discovery.jar
gnumail.jar
inetlib.jar
J7Zip.License
jaxrpc.jar
jmimemagic-0.1.0.license
jrpm-SNAPSHOT.jar
wsdl4j.jar

Brauchen wir anscheinend alle nicht?

Ja das habe ich mal gecheckt, und bin dabei darauf gekommen, dass man auf die folgenden libs wohl verzichten kann;
Code: Alles auswählen
commons-discovery.jar
gnumail.jar
inetlib.jar
jaxrpc.jar
wsdl4j.jar

ein ganz merkwürdiges Verhalten zeigt 'activation.jar': Wenn man es raus läßt, gibts keine Compile-Fehler von Eclipse. Ein ant clean all dist sagt aber das ginge nicht, weil eine Abhängigkeit zu activation.jar noch nicht da wäre. Die anderen jars konnte ich nicht raus nehmen, die waren irgendwo als lib eingezeichnet. SVN 6204

@e-user: kannst du die vier libs ebenfalls aus der Liste Löschen.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon Lotus » Mo Jul 13, 2009 5:25 pm

Orbiter hat geschrieben:./addon/jsmooth/lib/jsmoothgen-ant.jar
@Lotus: brauchst du das, um Windows-Builds zu machen? egal ob ja oder nein: Ist wohl nicht relevant für fedora und kann dort raus
@e-user: das muss nicht ins fedora

./lib/sbbi-upnplib-1.0.4.jar
@Lotus: kannst du mal gucken was wir damit machen? raus nehmen würde ich das nicht wollen. Ideen?

./libbuild/nsisant-1.2.jar
@flori: wer braucht das? der YaCy Source code nicht. du hast das vor einem Jahr eingebaut. Brauchen wir das noch?

jsmoothgen brauche ich nicht. Kann raus. Das kann eine .exe statt .java machen und man könnte auf die Windows-API zugreifen. Die exe macht keinen Sinn, weil ich das Windows-Release so mache, dass es identisch (bis auf Shortcuts) und kompatibel mit dem Archiv ist.

nsisant brauche ich fürs Windows-Release, damit NSIS aufgerufen wird (exe-Packer).

Die Sourcen der upnplib sind ca. 500KB groß und würden uns wahrscheinlich noch mehr libs ans Bein binden. Im Source-Archiv sind noch einige mehr mitgeliefert als wir momentan dafür brauchen.
http://www.sbbi.net/site/downloads/sbbi ... 0.4.tar.gz
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mo Jul 13, 2009 7:16 pm

ok, jsmooth ist raus, SVN 6205
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon dulcedo » Di Jul 14, 2009 8:13 am

Ich bekomme unter Ubuntu Intrepid beim System-Update (6194->6206) die Meldung ich hätte über apt-get installiert und soll bitte darüber updaten, das ist aber nicht der Fall. Danach dann
Code: Alles auswählen
Einen Moment bitte!
Installiere Release yacy_v0.91_20090714_6206.tar.gz
YaCy wird nach der Installation neugestartet


Und Neustart, neue Version. Entweder stimmt die Meldung nicht oder er updatet immer über den internen Mechanismus.

EDIT: Unter Win kommt die Meldung auch, also Fall1.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Di Jul 14, 2009 8:53 am

Update!
http://akahl.fedorapeople.org/yacy/yacy.org
http://akahl.fedorapeople.org/yacy/yacy.spec

Bitte gleich mal auf Korrektheit pruefen und alles mit einem Fragezeichen versehene beantworten. Mir kommen gleich wieder Fragen auf:
- Wird es ein Build-Target fuer die JUnit-Tests geben?
- Warum jrpm-SNAPSHOT.jar? Ist auf deren VCS doch noch Aktivitaet zu verzeichnen?
- Etwas Grundsaetzliches: Waere es nicht einfacher, im SVN ohne JARs zu arbeiten sondern ein Build-Target mitzuliefern, dass auf Bedarf die JARs von Upstream oder von einem eigenen Mirror besorgt? So waere es einfacher, je nach Anwendungsfall bzw. Zielpublikum Releases zu erstellen, mit oder ohne JARs. Und es spart Bandbreite und damit Geld :)

Was ich Florian schon geschrieben habe: Wir haben ein Tool zur Verfuegung, dass gegen eine Liste generischer Java-Paketnamen (installiert) die absoluten Pfade zu den JAR-Files generiert - das sollte noch einiges vereinfachen.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Di Jul 14, 2009 12:40 pm


- bitte in yacy.spec noch alle libx durch lib ersetzen
- ich habe nun das tar.jar entfernt, und durch Sourcen aus den apache ant tools übernommen. SVN 6212.
- in diesem Zusammenhang: bzip2 hast du in yacy.org als 'ant lib' gekennzeichnet. Da ist das auch drin, wir laden das als "import org.apache.tools.bzip2.CBZip2InputStream;". Das bzip2.jar kommt hier her: http://www.kohsuke.org/bzip2/
Der macht ein repackaging, aber die package-names sind wie in org.apache. Könnten wir auch so machen für das tar?

e-user hat geschrieben:- Wird es ein Build-Target fuer die JUnit-Tests geben?

womöglich? (wer arbeitet damit? ich nicht). Jedenfalls ist das nichts was in ein binary release muss.

e-user hat geschrieben:- Warum jrpm-SNAPSHOT.jar? Ist auf deren VCS doch noch Aktivitaet zu verzeichnen?

@alle: bitte mal gucken.

e-user hat geschrieben:- Etwas Grundsaetzliches: Waere es nicht einfacher, im SVN ohne JARs zu arbeiten sondern ein Build-Target mitzuliefern, dass auf Bedarf die JARs von Upstream oder von einem eigenen Mirror besorgt? So waere es einfacher, je nach Anwendungsfall bzw. Zielpublikum Releases zu erstellen, mit oder ohne JARs. Und es spart Bandbreite und damit Geld :).

ääh, das läd mir dann bei jedem 'ant clean all dist' alle jars neu? das spart dann aber keine Bandbreite, zumindest nicht solange die Anzahl der User nicht signifikant höher ist als die der Developer.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon flori » Di Jul 14, 2009 2:09 pm

Orbiter hat geschrieben:
e-user hat geschrieben:- Warum jrpm-SNAPSHOT.jar? Ist auf deren VCS doch noch Aktivitaet zu verzeichnen?

@alle: bitte mal gucken.

Das letzte SVN-commit war laut http://sourceforge.net/projects/jrpm/ im Jan 2009.

Orbiter hat geschrieben:
e-user hat geschrieben:- Etwas Grundsaetzliches: Waere es nicht einfacher, im SVN ohne JARs zu arbeiten sondern ein Build-Target mitzuliefern, dass auf Bedarf die JARs von Upstream oder von einem eigenen Mirror besorgt? So waere es einfacher, je nach Anwendungsfall bzw. Zielpublikum Releases zu erstellen, mit oder ohne JARs. Und es spart Bandbreite und damit Geld :).

ääh, das läd mir dann bei jedem 'ant clean all dist' alle jars neu? das spart dann aber keine Bandbreite, zumindest nicht solange die Anzahl der User nicht signifikant höher ist als die der Developer.

Sowas kann ich bauen, auch ohne dass das bei jedem ant clean die jars wieder löscht. Der Vorteil Bandbreite ist aber minimal. Die Releases müssen ja immer noch mit Jars ausgeliefert werden und das SVN wird nicht so oft komplett neu ausgecheckt (abgesehen davon das das SVN auf Berlios kommt). Ein Vorteil wäre, dass wir weniger Binarycode im SVN haben.
flori
 
Beiträge: 245
Registriert: Mi Jun 27, 2007 10:17 pm
Wohnort: Karlsruhe

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Di Jul 14, 2009 2:24 pm

ich habe in anderen Projekten ziemlich blöde Erfahrungen gemacht mit 'Nachladen aus dem Internet'. Es gibt viele Umgebungen, wo man eine Internetverbindung nicht hat oder will. Letzteres ist hier im Produktionsumfeld einer anderen Software schon ein ziemliches Problem gewesen: man muss erst in einer künstlich geschaffenen, produktionsähnlichen Umgebung Dinge zusammenbasteln, um sie dann in die Produktion schieben zu können. Beim testen gibts schlimme turnaround-Zeiten.
Dann gibts bei mir auch noch das Thema offline-Entwicklung: bin oft unterwegs ohne dsl, da macht das Nachladen kein Spass. Wenn es sich irgendwie vermeiden liesse, hätte ich die libs gerne permant im SVN und im Built-Code.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon Low012 » Di Jul 14, 2009 3:25 pm

Orbiter hat geschrieben:
e-user hat geschrieben:- Wird es ein Build-Target fuer die JUnit-Tests geben?

womöglich? (wer arbeitet damit? ich nicht). Jedenfalls ist das nichts was in ein binary release muss.

Ich bin beruflich zur Zeit ja eher im Bereich "Forschung" unterwegs und da geht es eher darum, Prototypen zu bauen und erstmal zu schauen, ob Dinge überhaupt machbar sind. Früher oder später würde ich aber schon gerne (zumindest beruflich) mit JUnit arbeiten und YaCy wäre dann wahrscheinlich auch ein erstes Opfer, um mal ein bisschen rumzuspielen. Ob das aber überhaupt was wird und wann... Keine Ahnung!
Low012
 
Beiträge: 2214
Registriert: Mi Jun 27, 2007 12:11 pm

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Di Jul 14, 2009 4:27 pm

Orbiter hat geschrieben:- bitte in yacy.spec noch alle libx durch lib ersetzen

Die massgebliche Datei ist immer noch yacy.org.. in der .spec sind nur Kommentare, sozusagen. Am Ende wird das .spec noch mal aktualisiert mit allem.

Orbiter hat geschrieben:- in diesem Zusammenhang: bzip2 hast du in yacy.org als 'ant lib' gekennzeichnet. Da ist das auch drin, wir laden das als "import org.apache.tools.bzip2.CBZip2InputStream;". Das bzip2.jar kommt hier her: http://www.kohsuke.org/bzip2/
Der macht ein repackaging, aber die package-names sind wie in org.apache. Könnten wir auch so machen für das tar?


bzip2.jar kommt fuer Fedora raus, stattdessen wird einfach tar.jar in den Include-Pfad geladen, das waere vollkommen i.O. (Falls Du das nicht ohnehin schon so meinst!)

Orbiter/Low012 hat geschrieben:->junit: womöglich? (wer arbeitet damit? ich nicht). Jedenfalls ist das nichts was in ein binary release muss.
(...)
Ich bin beruflich zur Zeit ja eher im Bereich "Forschung" unterwegs und da geht es eher darum, Prototypen zu bauen und erstmal zu schauen, ob Dinge überhaupt machbar sind. Früher oder später würde ich aber schon gerne (zumindest beruflich) mit JUnit arbeiten und YaCy wäre dann wahrscheinlich auch ein erstes Opfer, um mal ein bisschen rumzuspielen. Ob das aber überhaupt was wird und wann... Keine Ahnung!


Ich habe nur nach dem letzten `svn up` gesehen, dass junit.jar sowie einige Testklassen aufgetaucht sind jedoch ohne Test-Target. Wenn es schon Tests gibt, waere es gut, wenn diese ausfuehrbar sind - es ist bei uns sogar Pflicht, alle mitgelieferten Tests auszufuehren.

Orbiter/flori hat geschrieben:ääh, das läd mir dann bei jedem 'ant clean all dist' alle jars neu? das spart dann aber keine Bandbreite, zumindest nicht solange die Anzahl der User nicht signifikant höher ist als die der Developer.
(...)
Sowas kann ich bauen, auch ohne dass das bei jedem ant clean die jars wieder löscht. Der Vorteil Bandbreite ist aber minimal. Die Releases müssen ja immer noch mit Jars ausgeliefert werden und das SVN wird nicht so oft komplett neu ausgecheckt (abgesehen davon das das SVN auf Berlios kommt). Ein Vorteil wäre, dass wir weniger Binarycode im SVN haben.
(...)
ich habe in anderen Projekten ziemlich blöde Erfahrungen gemacht mit 'Nachladen aus dem Internet'. Es gibt viele Umgebungen, wo man eine Internetverbindung nicht hat oder will. Letzteres ist hier im Produktionsumfeld einer anderen Software schon ein ziemliches Problem gewesen: man muss erst in einer künstlich geschaffenen, produktionsähnlichen Umgebung Dinge zusammenbasteln, um sie dann in die Produktion schieben zu können. Beim testen gibts schlimme turnaround-Zeiten.
Dann gibts bei mir auch noch das Thema offline-Entwicklung: bin oft unterwegs ohne dsl, da macht das Nachladen kein Spass. Wenn es sich irgendwie vermeiden liesse, hätte ich die libs gerne permant im SVN und im Built-Code.
(...)


Es bedarf hier also der Klaerung und eines Plaedoyers :)
Use-Case "Initial Checkout": Ich checke zum ersten Mal die Quellen aus um mitzuentwickeln oder "bleeding edge" zu sein. In jedem Fall brauche ich die Abhaengigkeiten irgendwoher, wobei ich evtl. andere Versionen etc. benutzen moechte.
Loesung: Ein Build-Target, dass alle (noch fehlenden) JARs von einem YaCy-eigenen Mirror besorgt. Egal woher, der Download muss einmalig erfolgen.

Use-Case "Update": Ich moechte, bei einem bereits vorhanden Checkout, die neuesten Quellen und Abhaengigkeiten haben.
Loesung: Dasselbe ant-Update-Target, welches geaenderte Abhaengigkeiten in Form fehlender JARs prueft und ggf. nachlaedt von o.g. Mirror.

Use-Cases "Sourcen ohne JARs besorgen" und "Reines Source-Release anfertigen": Ich moechte an die YaCy-Quellen zum Selberbauen oder Releasen (Source-Release) heran kommen, ohne den Ballast von bei mir bereits vorhandener Abhaengigkeiten.
Loesung: Bereits impliziert, da nicht im SVN vorhanden.

Summa summarum: Wenn sich JARs aendern, muessen sich eh irgendwoher nachgeladen werden. Binaercode gehoert i.d.R. eh nicht ein ein VCS, da keine Delta-Diffs angewendet werden koennen und eine Trennung zwischen Code und Abhaengigkeiten vorliegen sollte (Maxime).
Die Vorteile liegen auf der Hand:
- Absolut niemand laedt mehr herunter, als er/sie muss.
- Bis auf einen Befehl nach jedem Checkout hat niemand mehr Arbeit.
- Jede Person, die nur die Sourcen moechte, laedt mehr herunter als unbedingt noetig
- Wichtiger Punkt: Downstream-Mirrors (a la Package-Repositories) werden nicht unnoetig vollgemuellt, denn mit jedem YaCy-Release steigt die Anzahl innerhalb des SRPMs oder Source-DEB verschwendeten Speicherplatzes seiten jeden einzelnen Distributions-Mirrors PRO unterstuetzter Major-Version der Distribution PRO unterstuetzer Architektur bei architekturabhaengigen Builds (Ihr benutzt kein JNI, oder?)

Sagen wir, es gaebe 50MB an Abhaengigkeiten und keine Rein-Source-Releases; eine Distribution unterstuetzt drei verschiedene YaCy-Versionen fuer drei verschiedene, noch unterstuetzte Major-Releases (typischer Fall) und hat 50 Mirrors. Es werden also dauerhaft 50MB*3*3*50 = 22,5GB Speicherplatz verschwendet fuer SRPMs oder Aequivalente. Fuer architekturabhaengige Pakete multipliziert sich das mit der Anzahl der Architekturen; ferner werden beim Bauen fuer jede Architektur bei jeder YaCy-Version im Build-Clusterverbund diese 50MB innerhalb des SRPMs an Bandbreite unnoetig uebertragen.

Selbst, wenn es Rein-Source-Releases gibt aber die JARs trotzdem im VCS gehalten werden: Es ergeben sich nur Nachteile, siehe Use-Cases. Optimalerweise enthaelt ein VCS immer nur das, was sich nicht erzeugen oder anderswo besorgen laesst, sprich nur Sources, Mediendateien, Templates. API-Doku, Binaerdateien etc. lassen sich generieren und Abhaengigkeiten lassen sich separat besorgen, und wenn es von einem eigenen Mirror ist.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Lotus » Di Jul 14, 2009 7:35 pm

Was ist mit den Libs in der .org-Datei, die unter "need packaging" stehen? Speziell die commons-jxpath . Die wird nämlich mindestens noch gebraucht wenn die sbbi-upnplib als Source eingebunden wird.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 9:23 am

Frei nach dem Motto, "machen, nicht labern" habe ich fuer YaCy ein GNU Makefile geschrieben (ich mag ant nicht), welches, wie in meinem letzten Beitrag beschrieben, fehlende JARs nachholt und veraltete loescht: http://akahl.fedorapeople.org/yacy/Makefile

Ihr muesst nur noch die JARs an einen HTTP-zugaenglichen Ort legen (ausserhalb des SVN!) und `MIRRORURL` im Makefile auf diesen Ort anpassen sowie die Liste `DEPENDENCIES` auf den aktuellen Stand der JARs bringen.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 15, 2009 9:53 am

Die Mirror-Rechnung habe ich nicht verstanden. Es geht doch bei dem fedora-release darum, die jars nicht beizulegen, und daran arbeiten wird ja hier gerade. Beim Development gibt es aber gar keine Mirrors, nur unser svn repository auf berlios und damit kommen wir doch prima klar!
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 10:07 am

Orbiter hat geschrieben:Die Mirror-Rechnung habe ich nicht verstanden. Es geht doch bei dem fedora-release darum, die jars nicht beizulegen, und daran arbeiten wird ja hier gerade. Beim Development gibt es aber gar keine Mirrors, nur unser svn repository auf berlios und damit kommen wir doch prima klar!


Es gibt nicht nur installerfaehige Binaer-RPMs, sondern auch SRPMs; diese enthalten das Specfile, die Sourcen und alle Patches. Ein solches SRPM exisitiert automatisch fuer jeden Architektur-Satz eines RPM und muss mitgespiegelt werden. IIRC ist dies fuer Debian analog genau so.

Das ist, wie gesagt, der negative Seiteneffekt, dass es von YaCy keine Source-only-Releases gibt.
Die Zusammenfassung meiner Argumentation ist: Werden Dependencies und Sources getrennt gehalten und erstere lassen sich trotzalledem bei Bedarf leicht nachladen und aktualisieren, ist das Gesamtauskommen von Kleinhaltung negativer Seiteneffekte und minimalem Verwaltungsaufwand gegenueber dem Nutzen optimal.

Addendum: Das Makefile aus letztem Beitrag soll genau dies bewerkstelligen. Auf jedes "svn up" muesste damit nur ein "make" folgen und schon hat jeder bei Bedarf seine Abhaengigkeiten gleich dabei.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 15, 2009 10:18 am

achso, es geht um ein source-only release ohne jars. Aber brauchen wir so ein Release jetzt für fedora? Wenn nicht würde ich das Thema gerne hier aussen vor lassen, und Vor- und Nachteile in einem eigenen Topic behandeln, damit hier der fokus nicht verloren geht. Wir bauen ja hier gerade nur für das Ziel ein fedora-Release zu bekommen ziemlich viel um, ich würde den Aufwand gerne so gering wie möglich halten, denn der ist schon groß genug. Wenn wir das fedora-Release schaffen kann man ja immer noch nach einem source-only release schauen, dann sind die Quellen auch schöner strukturiert.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 10:34 am

Orbiter hat geschrieben:achso, es geht um ein source-only release ohne jars. Aber brauchen wir so ein Release jetzt für fedora? Wenn nicht würde ich das Thema gerne hier aussen vor lassen, und Vor- und Nachteile in einem eigenen Topic behandeln, damit hier der fokus nicht verloren geht. Wir bauen ja hier gerade nur für das Ziel ein fedora-Release zu bekommen ziemlich viel um, ich würde den Aufwand gerne so gering wie möglich halten, denn der ist schon groß genug. Wenn wir das fedora-Release schaffen kann man ja immer noch nach einem source-only release schauen, dann sind die Quellen auch schöner strukturiert.


Zumindest fuer das Thema "Fedora-Package" ist es sehr relevant, ob es von YaCy regulaer und parallel zu den bisherigen Binaer-Releases auch Source-only-Releases gibt.
Die Frage ist, warum man es nicht gleich "richtig" machen soll - die JARs an einen Ort spiegeln, Makefile anpassen+committen und die JARs aus dem SVN entfernen, fertig :)
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 15, 2009 10:44 am

hmm, es ist ja nicht ganz so einfach:
- für 'Jars an einen Ort Spiegeln' ergibt sich für mich eine neue Verwaltungsaufgabe.
- 'Jars aus dem SVN entfernen' finde ich schon ein wenig problematisch, da dann ein Entwickler auch keine mehr rein tun darf, wenn er eine neue library aufnehmen möchte. Er müsste dann immer mich kontaktieren, und ich lege das dann an den jar-mirror. Finde ich ein wenig aufwendig, und nicht sehr 'dezentral'. Ich will ja auch mal in Urlaub fahren können, ohne dass das development gezwungenermassen still steht.

Kann man dafür nicht einfach das http interface des SVN nehmen:
http://svn.berlios.de/svnroot/repos/yacy/trunk/lib/
da liegen doch die libs nun alle schön drin und kann man per http runterziehen. Funktioniert das in deinem Script?
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon flori » Mi Jul 15, 2009 10:47 am

Ich seh das eher so, das wir einen deutlich höheren Verwaltungsaufwand haben, weil wir ein Webspace brauchen, der möglichst für jeden Entwicker zugänglich sein sollte. Außerdem hat dieser Webspace dann keine Versionsverwaltung. Von der Möglichkeit, nur das downzuloaden, was man gerade braucht, kann man zur Zeit gar nicht gebrauch machen, weil man fast alle Abhängigkeiten zum Kompilieren brauch.
Ein ant-Target, was keine Class-Dateien ausliefert gibt es schon, es heißt sdist. Eventuell muss man es noch anpassen.
flori
 
Beiträge: 245
Registriert: Mi Jun 27, 2007 10:17 pm
Wohnort: Karlsruhe

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 10:50 am

Orbiter hat geschrieben:hmm, es ist ja nicht ganz so einfach:
- für 'Jars an einen Ort Spiegeln' ergibt sich für mich eine neue Verwaltungsaufgabe.
- 'Jars aus dem SVN entfernen' finde ich schon ein wenig problematisch, da dann ein Entwickler auch keine mehr rein tun darf, wenn er eine neue library aufnehmen möchte. Er müsste dann immer mich kontaktieren, und ich lege das dann an den jar-mirror. Finde ich ein wenig aufwendig, und nicht sehr 'dezentral'. Ich will ja auch mal in Urlaub fahren können, ohne dass das development gezwungenermassen still steht.

Kann man dafür nicht einfach das http interface des SVN nehmen:
http://svn.berlios.de/svnroot/repos/yacy/trunk/lib/
da liegen doch die libs nun alle schön drin und kann man per http runterziehen. Funktioniert das in deinem Script?


Klar geht das, SVN benutzt ja auch bloss HTTP hier :)
Man koennte z.B. http://svn.berlios.de/svnroot/repos/yacy/deps/ hierfuer anlegen und schon koennt Ihr nach beliegen Abhaengigkeiten auch im SVN getrennt verwalten.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 15, 2009 11:00 am

flori hat geschrieben:Ein ant-Target, was keine Class-Dateien ausliefert gibt es schon, es heißt sdist. Eventuell muss man es noch anpassen.

könntest du das mit e-users make pimpen, bzw. so bauen das es das gleiche macht? e-user: eine weitere built-Sprache rein nehmen finde ich nicht gut, aber trotzdem danke für den Vorstoss. Bei Java-apps sind ja ant builts üblicher, kann aber sicherlich auch sein dass man das im Kontext zu SRPMs anders macht.

e-user hat geschrieben:Man koennte z.B. http://svn.berlios.de/svnroot/repos/yacy/deps/ hierfuer anlegen und schon koennt Ihr nach beliegen Abhaengigkeiten auch im SVN getrennt verwalten.

wofür brauchen wir die deps? bzw. was soll da drin sein was nicht in lib ist?
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 11:17 am

Orbiter hat geschrieben:e-user: eine weitere built-Sprache rein nehmen finde ich nicht gut, aber trotzdem danke für den Vorstoss. Bei Java-apps sind ja ant builts üblicher, kann aber sicherlich auch sein dass man das im Kontext zu SRPMs anders macht.


Ihr nutzt doch jetzt schon M4 bzw. flori plant es zu nutzen :) Manchmal ist ant oder Java einfach "zu viel" oder "zu umstaendlich". Ich wuesste nicht, wie man die Logik aus dem Makefile einfach nach ant ohne komplexe Java-Zusatzklassen abbilden koennte.

Orbiter hat geschrieben:wofür brauchen wir die deps? bzw. was soll da drin sein was nicht in lib ist?


Fuer alles, was jetzt in `lib` ist. Einfach YaCy im SVN und in dem Source-Releases ohne `lib` ausliefern und wer die Deps moechte, laedt sie mit `make` nach.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 15, 2009 11:30 am

warum lib nach debs umkopieren, bzw. aus lib raus nehmen? Das lib gehört da einfach hin, und auf das bisherige generische full-tarball will ich auch nicht verzichten. Wenn man ein source-release will, kann man das doch auch so bauen.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 11:42 am

Orbiter hat geschrieben:warum lib nach debs umkopieren, bzw. aus lib raus nehmen? Das lib gehört da einfach hin, und auf das bisherige generische full-tarball will ich auch nicht verzichten. Wenn man ein source-release will, kann man das doch auch so bauen.


Weil man dann fuer ein Source-Release alles fuer ein Full-Release unnoetig herunterladen muss, um es dann gleich wieder zu loeschen. Beim naechsten `svn up` ist der ganze Muell sogar wieder da, selbst, wenn man ihn nicht brauch oder moechte.
Umgekehrt, mit dem Makefile: Ich lade mir den Source (und nur den!) und die JARs mit einem `make` nach fuer ein Full-Release. Laesst sich auch ins ant-Target einbauen.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Orbiter » Mi Jul 15, 2009 11:59 am

das mag sein, aber hier geht es ja um ein SRPM, das man aus einem built-script bekommt. Das stellt ja ein developer explizit zur Verfügung. Da haben wir ja alles was wir brauchen.

Um das ganze noch mal von einer anderen Seite zu beleuchten: ich komme teilweise an die SVN-Daten nur über 'komplizierte' Tunnels, mehr kann ich hier nicht sagen 8-) . Wenn dann da noch Nachlade-Effekte über nicht-verbiegbare Kanäle rein gehen, dann erschwert mir das die Geschichte ein wenig...

Wenn aus Anwendersicht nie ein svn up gemacht werden muss, haben wir hier doch kein Problem, oder?
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 1:16 pm

Orbiter hat geschrieben:das mag sein, aber hier geht es ja um ein SRPM, das man aus einem built-script bekommt. Das stellt ja ein developer explizit zur Verfügung. Da haben wir ja alles was wir brauchen.

Solange ich im SPECfile bei jedem neuen YaCy-Release eine URL mit Rein-Source-Release referenzieren kann, ist es schon die halbe Miete.
Das mit den Dependencies war auch nur ein Verbesserungsvorschlag, es ist kein "Muss" fuer das Fedora-Paket.

Orbiter hat geschrieben:Um das ganze noch mal von einer anderen Seite zu beleuchten: ich komme teilweise an die SVN-Daten nur über 'komplizierte' Tunnels, mehr kann ich hier nicht sagen 8-) . Wenn dann da noch Nachlade-Effekte über nicht-verbiegbare Kanäle rein gehen, dann erschwert mir das die Geschichte ein wenig...

Ach da laeuft der Hase :) OK

Orbiter hat geschrieben:Wenn aus Anwendersicht nie ein svn up gemacht werden muss, haben wir hier doch kein Problem, oder?

Aeh? Ich meinte ja Bleeding-Edge-Anwender im Use-Case.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Lotus » Mi Jul 15, 2009 2:16 pm

Lotus hat geschrieben:Was ist mit den Libs in der .org-Datei, die unter "need packaging" stehen? Speziell die commons-jxpath . Die wird nämlich mindestens noch gebraucht wenn die sbbi-upnplib als Source eingebunden wird.

@e-user: ist geplant dafür ein package zu machen?
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Mi Jul 15, 2009 2:31 pm

Lotus hat geschrieben:
Lotus hat geschrieben:Was ist mit den Libs in der .org-Datei, die unter "need packaging" stehen? Speziell die commons-jxpath . Die wird nämlich mindestens noch gebraucht wenn die sbbi-upnplib als Source eingebunden wird.

@e-user: ist geplant dafür ein package zu machen?

Fuer alles, was benoetigt wird und *nicht* Teil von YaCy ist/wird/sein kann etc. muss sauber ein Package gemacht werden bzw. von JPackage portiert, ja. Genau dafuer steht der Punkt "Need packaging".
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon e-user » Do Jul 16, 2009 9:56 am

Update!
http://akahl.fedorapeople.org/yacy/yacy.org
http://akahl.fedorapeople.org/yacy/yacy.spec
http://akahl.fedorapeople.org/yacy/pdfbox.spec

Positive Neuigkeiten: Fuer
- ./lib/bcprov-jdk14-139.jar
- ./lib/bcmail-jdk14-139.jar
- ./lib/activation.jar

Habe ich doch Entsprechungen in vorhandenen Fedora-Paketen gefunden, in derselben Reihenfolge nach Zugehoerigkeit:
- bouncycastle
- bouncycastle-mail
- classpathx-jaf

Damit bleiben nach aktuellem Stand nur
- fontbox
- pdfbox
- jakarta-poi
- und jakarta-commons-jxpath
zu paketieren.

Zu ./lib/J7Zip-modified.jar haette ich noch eine Frage: Ist es so, wie der Name vermuten laesst, eine modifizierte Version von J7Zip? In diesem Faelle koennte das Ding auch fast unmodifiziert bleiben, mit der Ausnahme, dass es ebenfalls von Source innerhalb YaCy baubar sein muss, auch, wenn es in einem eigenen JAR bleibt. In diesem Falle wuerde es nach /usr/share/java/yacy/ installiert werden.

Wie oben zu sehen, habe ich ausserdem mit dem PDFBox-Port von JPackage zu Fedora angefangen.
e-user
 
Beiträge: 23
Registriert: Mi Jul 01, 2009 8:37 am
Wohnort: Berlin x-berg

Re: Linuxtag Idee: Fedora Package

Beitragvon Lotus » Do Jul 16, 2009 10:24 am

Auch noch ein update von unserer Seite:
tar und
sbbi-upnplib
haben wir nun als Source drin. Kann also aus der Liste gestrichen werden.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Nächste

Zurück zu Wunschliste

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast