Vor- und Nachteile von Repo's

[Patsche]

Hi,

ich habe schon öfter Kontakt zu Entwicklern gehabt, die Linuxprogramme vertreiben, diese aber nicht in die Quellen stellen, weil es ihnen zu schwierig scheint sich in jedes System einzuarbeiten. Auch meinten Sie, dass sie dann nicht mehr Herr über ihren Quellcode wären, der dort angeboten. Ist das richtig? Ich kann es verstehen: Man muss über jedes Distribution genau Bescheid wissen. Selbst wenn es nur die gängigsten wären. Jedes Distro hat andere Aufnahmerichtlinen für Programme und andere Veröffentlichungsrhytmen. Gerede jetzt habe ich eine Diskussion mit dem Hauptentwickler von PaleMoon, warum er den Browser nicht in die Debian Quellen integrieren will. Eines seiner Hauptargumente liegt daran, dass Debian es schon mit Firefox nicht hinbekommen hat. Er möchte nicht, dass sein PaleMoon modifiziert bei Debian angeboten wird. Was meint ihr?

[Meillo]

Was meint ihr?

Ich meine, dass die Paketierung fuer Distributionen *keine* Upstreamaufgabe ist. Der Upstream-Entwickler kann das, wie du schon schreibst, gar nicht leisten. Die Anzahl und Vielfalt der Distributionen ist zu gross, deren Regelwerke sind zu umfangreich und aendern sich zu schnell, und somit kann ein Upstream-Entwickler praktisch kaum eine Paketier-Qualitaetsarbeit abliefern. Meiner Meinung nach sollte es hier eine klare Aufgabenteilung zwischen Upstream-Entwicklern und Paketierern aus den Distributionen geben. Das Problem, das ich aber sehe, ist die zu kleine Anzahl an Paketierern ueberhaupt und noch mehr bei denen die langfristig aktiv sind. Komplexe Paketierregelwerke wie die von Debian z.B. belasten diese Situation leider zusaetzlich (was aber nicht heissen soll, dass das nicht andere Vorteile haette).

Dass die Distributionserstellung (inklusive Paketierung) eine separate Aufgabe ist, finde ich uebrigens sehr angemessen und wertvoll.

Ich wuerde deshalb sagen: Mehr Paketierer braucht die Welt!


(btw: Ich haette da auch noch ein Debianpaket abzugeben. )

[hikaru]

Auch meinten Sie, dass sie dann nicht mehr Herr über ihren Quellcode wären, der dort angeboten. Ist das richtig?

Das ist richtig, es sei denn sie sind auch Paketbetreuer. Warum das eher selten der Fall ist hat Meillo bereits erwähnt.
Allerdings halte ich die Einstellung "Herr über seinen Quellcode" sein zu wollen für fragwürdig im Zusammenhang mit Freier Software.
Dafür, dass man das womöglich nicht unter "seinem" Namen möchte habe ich Verständnis. Aber man sollte anderen dann nicht vorhalten wenn sie einem das Projekt "miniforken".

Gerede jetzt habe ich eine Diskussion mit dem Hauptentwickler von PaleMoon, warum er den Browser nicht in die Debian Quellen integrieren will. Eines seiner Hauptargumente liegt daran, dass Debian es schon mit Firefox nicht hinbekommen hat.

Wenn ich mir die Bedingungen [1] anschaue unter denen der Name "Pale Moon" und die Grafiken verwendet werden dürfen, dann erinnert mich das (sicher nicht von ungefähr) sehr stark an die Ansichten von Mozilla.
Die Aussage, "dass Debian es schon mit Firefox nicht hinbekommen hat" finde ich sträflich einseitig betrachtet. Beide zusammen haben es nicht hinbekommen sich zu einigen. Da darf sich jede Seite zu gleichen Teilen an die eigene Nase fassen. Fakt ist nun mal, dass firefox in Debian bestenfalls ein non-free-Metapaket (plus Grafiken) sein könnte, das als Abhängigkeit den Firefox-Code aus contrib installiert. Und ob diese künstliche Rekombination dann noch mit Mozillas Ansichten vereinbar wäre würde ich sogar bezweifeln. Da finde ich iceweasel in main die bessere Lösung.
Wie wäre es denn mit brightsun in Debian?

Komplexe Paketierregelwerke wie die von Debian z.B. belasten diese Situation leider zusaetzlich (was aber nicht heissen soll, dass das nicht andere Vorteile haette).

Ich wuerde sagen: Mehr Paketierer braucht die Welt!

Sehe ich genauso. Ein Grund warum ich kein Paketierer bin ist, dass ich Debians Regelwerk diesbezüglich bis heute nicht völlig verstanden habe. Die Dokumentation dazu ist in meinen Augen zersplittert und die Aktualität fragwürdig.
Und um mich da mit fraglichem Ausgang durch ein Mentorenprogramm zu wurschteln bin ich einerseits zu faul und andererseits widerstrebt es meinem Anspruch an saubere Arbeit (v.a. an mich selbst), wenn es hauptsächlich daran hapert, dass das Projekt keine ordentliche Dokumentation auf die Reihe kriegt, die ja für jemanden der sich damit auskennt (was mMn auf alle Maintainer zutreffen sollte) im Grunde "nur" Fleißarbeit wäre.


[1] http://www.palemoon.org/branding.shtml

[deberik]

Auch meinten Sie, dass sie dann nicht mehr Herr über ihren Quellcode wären, der dort angeboten. Ist das richtig?

Das ist richtig, es sei denn sie sind auch Paketbetreuer. Warum das eher selten der Fall ist hat Meillo bereits erwähnt.
Allerdings halte ich die Einstellung "Herr über seinen Quellcode" sein zu wollen für fragwürdig im Zusammenhang mit Freier Software.

Sehe ich auch so, vor allem wenn die Basis dieses Quellcodes sowieso die Arbeit anderer war

Gerede jetzt habe ich eine Diskussion mit dem Hauptentwickler von PaleMoon, warum er den Browser nicht in die Debian Quellen integrieren will. Eines seiner Hauptargumente liegt daran, dass Debian es schon mit Firefox nicht hinbekommen hat.

Wenn ich mir die Bedingungen [1] anschaue unter denen der Name "Pale Moon" und die Grafiken verwendet werden dürfen, dann erinnert mich das (sicher nicht von ungefähr) sehr stark an die Ansichten von Mozilla. (...)

[1] http://www.palemoon.org/branding.shtml

Gemeinsam mit http://www.palemoon.org/redist.shtml wirkt das für mich, als ob es gezwungenermaßen Freie Software ist, aber alles versucht wird, um die Freiheit einzuschränken.

[hikaru]

Gemeinsam mit http://www.palemoon.org/redist.shtml wirkt das für mich, als ob es gezwungenermaßen Freie Software ist, aber alles versucht wird, um die Freiheit einzuschränken.

Ja, den Eindruck habe ich auch.

[Patsche]

Gerade bei freien Projekten stoße ich häufig auf unvollständige Dokumentationen oder verammelte Tore. Beispielsweise arbeite ich an der Wine-Datenbank mit und muss feststellen, dass viele eingereichte Test abgewimmelt werden mit: "Das Spiel läuft doch schon mit Version x auf Platin". Ich entgegne dann, dass es mal mit dieser Version lief, aber jetzt nicht mehr. Spiele erhalten auch Updates....tja und dann kommt nichts mehr.
Auch die Zusammenarbeit mit der freien Film und Serien Implementierung von xbmc gestaltet sich schwierig. Manche Serien haben in Deutschland eine andere Reihenfolge, als im Englischen. Wenn man dann seine Sammlung von xbmc durchsuchen lässt, dann stimmen die Beschreibungen nicht. Mann kann sie nicht bearbeiten, weil die Sendung als abgeschlossen gilt. Ja, super. Sehr frei. Eine Frage im Forum verläuft ins Leere. Alles soll frei sein, aber hat 1000 Regeln und Vorschriften. Mag ja manchmal nötig sein, aber oft ist es übertrieben. Aber ich schweife vom eigentlich Thema ab. Wollte nur was zum Thema unvollständige Doku und missglückten Rechtesystemen sagen.

[hikaru]

Gut, wenn wir schon dabei sind motze ich nochmal über Openstreetmap.
Ich hatte mal einen Bug gemeldet weil eine Stadt falsch getaggt war ("postcode" statt "postal code", oder andersrum). Als Ergebnis fand navit die Stadt nicht. Für den Bugreport habe ich einen Punkt auf der Karte markiert, der eigentlich ein recht zentraler Punkt der Stadt sein sollte (Marktplatz oder so). Der Report wurde mit der Begründung geschlossen, dass es an dieser Stelle keine Stadt gibt die man taggen könnte.
Formal korrekt, denn natürlich gab es dort keine Stadt - zumindest wenn man dem Tag glaubte. Fragt sich nur, was das Straßenknäuel da in der Pampa soll.

[Meillo]

OT:

Gut, wenn wir schon dabei sind motze ich nochmal über Openstreetmap.
Ich hatte mal einen Bug gemeldet weil eine Stadt falsch getaggt war ("postcode" statt "postal code", oder andersrum).

Das lasse ich nicht gelten! Ich beschaeftige mich seit einigen Wochen mit der OSM und kann sagen: Es gibt dort kein ``falsch getaggt'' nur ein ``ungeschickt getaggt''. Meine bisherigen Erfahrungen mit der Community waren auch grossteils richtig positiv. Dein Fall kann nicht der Normalfall sein.


... aber wir driften hier ganz schoen nach OT ab, auch mit der OpenMoon-Kritik. Selbst Patsche driftet mit ab. Hat sich also die urspruengliche Frage geklaert? Duerfen bzw. sollen wir jetzt gemeinsam, guten Gewissens abschweifen.

[Patsche]

Vielleicht hat ja jemand noch etwas zum "Ontopic-Thema" zu sagen. Ihr dürft aber gerne abschweifen

[eggy]

@meilo: welches isses denn?

etwas on topic:

Gegenargument: Diejenigen, die die Software schreiben sind auch diejenigen. die sie am besten paketieren könnten - in Bezug auf "was will ich in der Beschreibung haben", "welche Abhängigkeiten sind optional" usw.

Als ganz großen Vorteil von "Paket direkt in Debian" würde ich sehen, dass das Securityteam noch ein halbes Auge mit auf mein Zeug hat.

Der Nachteil anfangs Sponsoren zu brauchen, seh ich als nicht so gravierend. Was hindert mich, mein Paket sowohl auf meiner Homepage anzubieten als auch an den Sponsor zu schicken? Wenn das Paket nicht durch den Prozess kam, war es qualitativ nicht gut genug. Dann ist es doch nur gut, wenn jemand sagt "ey, so gehts aber nicht" (und netterweise gleich auch noch Ratschläge mitliefert wie es besser geht).

[hikaru]

Gegenargument: Diejenigen, die die Software schreiben sind auch diejenigen. die sie am besten paketieren könnten - in Bezug auf "was will ich in der Beschreibung haben", "welche Abhängigkeiten sind optional" usw.

Jein.
Was die Beschreibung angeht hast du natürlich recht.
Aber schon Abhängigkeiten (in Abgrenzung zu Empfehlungen und Vorschlägen) sind ein Thema das man eher aus Distributorsicht sehen muss. Vielleicht findet ja ein Entwickler ein bestimmtes Theme für seine Oberfläche ganz toll. Das darf dann gern ein Vorschlag oder gar eine Empfehlung, aber keine Abhängigkeit sein. Eine Abhängigkeit darf wirklich nur das sein was zur sinnvollen Benutzung zwingend notwendig ist.

Viel problematischer ist jedoch, dass ich mich als Entwickler und Paketierer einer Software in ein halbes Dutzend Paketverwaltungssysteme einarbeiten muss, die zwar alle ähnlich funktionieren, aber doch anders.
Ein Debianpaket kriege ich geschnürt, wenn auch nicht 100%ig sauber. Bei Slackware kriege ich das auch noch hin wenn ich mal ein paar graue Zellen abstaube. Ein RPM kann ich zumindest lesen, aber z.B. von Archs Paketen oder Gentoos ebuild-Scripts habe ich keine Ahnung.

Aber Entwickler und Paketierer arbeiten ja nicht im luftleeren Raum. Die sollten sich schon abstimmen, z.B. über die Beschreibung oder neue Releases.

[Meillo]

@meilo: welches isses denn?

Es scheint unterschiedlich zu sein, ob man Adresse (von Gebaeuden) oder Regionen die die gleiche PLZ haben taggt. Wie man es in dem konkreten Fall machen muesste weiss ich nicht (so viel Erfahrung habe ich noch nicht), aber ich weiss wo ich mir Informationen holen kann:
http://wiki.openstreetmap.org/wiki/DE:Key:postal_code
http://wiki.openstreetmap.org/wiki/DE:Key:addr

Zur absoluten Verbreitung der Tags (wenn das auch nicht unbedingt was aussagen muss!):
http://taginfo.openstreetmap.org/search?q=postal_code
http://taginfo.openstreetmap.org/search?q=addr:postcode

Und sonst halt einfach bei anderen Staedten schauen, bei denen die Navigation funktioniert, wie es dort gemacht worden ist.

Generell gilt aber die Regel, dass man das Tagging nicht den Renderern und Routenplanern anpassen sollte, sondern umgekehrt: Man taggt moeglichst semantisch korrekt und die aufsetzenden Programme muessen sich den ueblichen Taggingverfahren anpassen. Dieser Ansatz ist sicher sinnvoll, kann aber in Uebergangszeiten zu Unannehmlichkeiten fuehren. Im konkreten Beispiel war es vielleicht eine Folge dessen, dass sich das Karlsruhe Schema langsam durchgesetzt hat: http://wiki.openstreetmap.org/wiki/DE:Karlsruhe_Schema

Aber ich bin wie gesagt, kein Experte auf dem Gebiet.


----

etwas on topic:

Gegenargument: Diejenigen, die die Software schreiben sind auch diejenigen. die sie am besten paketieren könnten - in Bezug auf "was will ich in der Beschreibung haben", "welche Abhängigkeiten sind optional" usw.

``was will ich in der Beschreibung haben'' will ich nicht gelten lassen, da Upstream da meist recht eigene Vorstellungen hat, was er drin stehen haben *will*, die Paketierer sich aber vielmehr fragen, was fuer den Nutzer in der Beschreibung drin stehen *sollte*.

Bei den Abhaengigkeiten stimme ich dir zu, dass Upstream das oft (!) weiss, aber wenn er das weiss, dann kann er es ja auch weitergeben. Und schliesslich sollte es nicht um ein Entweder-Oder gehen, sondern die Paketierer sollten wenn moeglich immer im Kontakt mit Upstream stehen.

Wenn ich mir aber ueberlege wieviel Paketierfachwissen ich bei meinen Paketieranstrengungen (fuer Debian) notwendig gesehen habe, dann sehe ich darin eine viel groessere Huerde als darin die Abhaengigkeiten einer Software zu erfahren.

Hier mal ein paar Stichworte zum ordentlichen Paketieren fuer Debian:
- New-Maint-Guide gelesen (und verstanden) haben
- Dev-Reference in Auszuegen gelesen haben
- Debian-Policy verstehen (und ihre Aenderungen verfolgen)
- Die Paketiertools (dh_make, quilt, etc.) benutzen koennen
- pbuilder einrichten und verwenden

... und wenn man all das gemeistert hat und Erfahrung gesammelt hat, dann kann man Pakete *ordentlich* paketieren. (Quick'n'dirty geht's natuerlich schneller.) Noch nicht beinhaltet sind aber alle Arten von komplizierteren Faellen: Konfigurations-Transitions, Spezialsoftware (z.B. Daemonen), Release-Vorbereitungs-Besonderheiten, usw.

Wie das alles ein Upstream-Developer leisten soll ist mir unerklaerlich ... und dann haben wir ja erst Debian (und seine ``Kinder'') bedient.


EDIT:
Ich hoffe, ich habe euch jetzt nicht demotiviert, denn ich haette ja gerne mehr Paketierer.

[eggy]

@meilo: aehm nee, ich wollt wissen, welches Paket Du loswerden magst ... mit osm komm ich ganz gut klar

[Meillo]

@meilo: aehm nee, ich wollt wissen, welches Paket Du loswerden magst

Ahh.

Es geht um https://tracker.debian.org/pkg/masqmail

Das Paket ist zwar nicht im besten Zustand aber auch in keinem ganz schlechten. Es ist kein Anfaengerpaket aber ich habe damals auch damit angefangen. Ich habe es selber mal betreut und ich bin der Upstream-Entwickler, kann also helfen und bin an einer guten Zusammenarbeit interessiert, ich will die Paketiererei aber nicht mehr selber machen. Allzuviel passiert Upstream nicht, insofern sollte der Job eher ruhig sein, sobald man das Paket mal wieder auf den neuesten Stand gebracht hat.

[eggy]

@meilo: Ah Mailzeug, nichts für mich
Hast nen RFA/RFH aufgemacht? Ich habs auf http://wnpp.debian.net/ nicht gesehn.

[Meillo]

Hast nen RFA/RFH aufgemacht?

Nee, sollte ich mal machen ...