Aus der Antwort auf einen Bugreport von mir über eine völlig falsche Version von mod_perl 2:
I'm afraid you will be out of luck here, if I understand the issues correctly. The official release of mod_perl 2.0 never made it to Sarge, the 1.999.21-1 packages in Sarge is a pre-release. The problem was that shortly before mod perl2 went stable, the upstream developers decided to rename lots of things in the API, and Sarge shipped the old API. Thus, mod perl 2.0 as shipped with Sarge won't run in the rest of the world, and vice-versa. Also, the documentation will be confusing. [...] So, well, this isn't a good situation, but it is something we have to live with.
Bitte was? Die haben ja wohl ein Rad ab. Nochmal zum Mitmeißeln: die mod perl 2 Version in Debian Sarge - die aktuelle stabile Debian - ist weder mit der alten mod perl 1 Version noch mit der wirklichen mod perl 2 Version kompatibel, weil es eine 1.99sonstwas ist, die ein ziemlich an deres API hat. Anwendungen die darauf aufbauen sind nicht portabel von der alten Version und nicht portabel zur neuen Version. Wer mit der Debian Sarge und Apache2 und mod perl arbeiten will, muss sich erst einen Backport besorgen, denn die Version da drin ist einfach nur völlig falsch.
Sowas ist doch hirnrissig. Klar, gut, die mod perl 2 ist nicht rechtzeitig zum Release fertig geworden, aber die derzeitig in Sarge befindliche Version ist schlichtweg Müll. Und anstatt die rauszuwerfen wird so eine Zwischenversion reingepackt und jedem der mod perl Anwendungen auf Apache 2 portieren will das Leben schwer gemacht - und zwar gleich doppelt, denn mit dem nächsten Release darf man dann nochmal portieren.
Und heute nacht dann der Hammer:
The only valid complaint in this bug report is the fact that we don't include pre-2.0 API docs in sarge. Debian makes absolutely no guarantees that the version of a package shipped in a stable release will match whatever the current API is on its upstream website.
Zusammenfassung: wir haben nichts verstanden und bestehen darauf uns wie Vollidioten zu verhalten. Statt die schrottige Release - die auch von Upstream als "don't use" eingeordnet ist - wenigstens rauszuwerfen wird jetzt einfach nur als Wishlist-Bug die fehlende Dokumentation gelistet.
Wie jedes Jahr war wieder mal die lange Nacht der Museen in Münster. Irgendwas muss aber gegenüber letztem Jahr passiert sein. Letztes Jahr war das Interesse zwar gross, aber man konnte es noch als durchaus erträglich bezeichnen. In den Museen konnte man sich - zwar mit mehr Besuchern also sonst - durch die Räume bewegen. Nur das Picasso-Museum war auch letztes Jahr schon überfüllt und wurde nur Grüppchenweise zum Betreten freigegeben.
Diesesmal war daran nicht zu denken - das Landesmuseum für Kunst und Kultur ist ja nicht gerade klein. Trotzdem kam man in manche Räume nicht mehr rein vor lauter Leuten - die dann auch noch mit Führungen zu regelrechten Besucherpfropfen ganze Teile des Museums unerreichbar machten.
Absolut irre das ganze. Wahre Menschenhorden wälzten sich da durch die Stadt und bliesen zum gesammelten Angriff auf die Museen. Irgendwie leicht surreal das ganze
Philip J. Eby hackt mal wieder. Diesmal einen Parser für Konfigurationssprachen deren Syntax an Python angelehnt ist. Besonders interessant: mit dem Parser kann man sehr schön abstrakte Sprachen aufbauen die in Teilen einfach Python für Code benutzen - man kann enthaltene Python-Blöcke nämlich von der Token-Form wieder in sauber formatierten und eingerückten Python-Code umwandeln. Der Parser kennt natürlich all die Randfälle der Sourceformatierung in Python und kommt mit denen auch klar.
Interessant ist das ganze deshalb, weil man mit Python ja leider keine Makrosprache hat und deshalb eigene Syntaxerweiterungen und Sprachen mit domain-spezifischer Syntax und Semantik nicht direkt in Python abbildbar sind - aber man kann über diesen Parser einen Translator für solche DSLs bauen und diese dann wieder in Python wandeln. Dazu dann noch ein bischen Import-Magic und man hätte sowas wie poor-mans-macros für Python ...