fontconfig

[MustrumRidcully]

hi @all,

ich weiß, es ist ein eher abseitiges thema für dieses forum, aber vll. ist ja einer der user in der lage, mir aus dem stegreif ne befriedigende antwort zu geben. drum also:

ich fahre debian unstable und möchte nun, nachdem ich das ding mit dem pblic key endlich begriffen und gelöst habe, nach über einem halben jahr mal wieder ein upgrade durchführen. und seit mindestens zwei wochen hängt das upgrade an fontconfig uns seinen zwei open bugs:

Code: Alles auswählen

critical bugs of fontconfig (2.4.1-2 -> 2.4.2-1.2) <open>
 #423382 - crashes when updating fonts
grave bugs of fontconfig (2.4.1-2 -> 2.4.2-1.2) <open>
 #427447 - ttf-opensymbol: postinst script fail
Summary:
 fontconfig(2 bugs)

das seltsame ist, dass dieselben bugs auch auftreten, wenn ich meine sources.list auf testing umschreibe. klurz: wegen der open bugs in fontconfig ist ein upgrade weder für testing noch für unstable möglich.

kann jemand auskunft darüber geben, was da los ist? und vll. sogar, wann mit dem bugfix gerechnet werden kann?

many thx in advance
MR

[Aiellu]

zur zeit wird in testing sozusagen "mit der heissen nadel gestrickt", das heisst es werden jede menge neue unstable pakete ins testing durchgewunken, weil/obwohl noch nicht alle abhängigkeiten erfüllt sind. da hilft nur geduld haben und warten. und vielleicht erstmal bei etch bleiben bis sich in testing die neuerungs-wogen etwas geglättet haben.

[MustrumRidcully]

hmm... schade. aber danke für die info.
gibt es irgendeine art von timeline dafür? also wie z.b. bei mozilla, die ganz klar sagen: svg nicht vor version 3.0? das doofe ist ja, dass es grad die basis-pakete sind, die die offenen bugs haben. "libc6 reports a wrong version number" und so sachen...

[Aiellu]

genaue infos zum status findest du unter "Debian Release Management"

grundsätzlich richtet sich die aufnahme in "testing" nicht nach einer bestimmten versionsnummer, sondern nach der anzahl der bugs und den abhängigkeiten. sind in einem paket weniger als 5 bugs und sind alle abhängigkteiten innerhalb von "testing" für dieses paket erfüllt, wird das paket ins testing aufgenommen, wobei es sich bei den maximal möglichen bugs auch um critical bugs handeln kann.

rechenbeispiel: ein paket, zwei abhängige pakete: macht summa-summarum für diese 3 pakete insgesammt 15 bugs mit denen zu rechnen ist, auch critical bugs.

das lilemma der maintainer: sind die vorraussetzungen eines paketes für die aufnahme ins testing erfüllt, jedoch sind in den abhängigen paketen noch zu viele bugs kommt das paket nicht ins testing, egal wie viele andere aktuellere pakete mit ihren abhängigkeiten wegen ihrem erfüllten bug-maximum bereits durchgewunken wurden.

dies ist z.b. auch der grund warum debian in der vergangenheit sehr lange für ein stable release brauchte: pakete mussten lange zurück gehalten werden weil z.b. nur eine einzige lib noch zu viele bugs enthielt, und/oder der eine maintainer der (in der vergangenheit auf diesem einen lib regelrecht "saß") etwas geklüngelt hatte.

für die zukunft soll es daher so sein dass mehrere maintainer sich um ein paket kümmern können, sodass es quasi "vorran" geht und nicht auf einzelne pakete unnötig lange gewartet werden mussen und der entwicklungs-/testingprozess aufgehalten wird.

bis sich das ganze jedoch eingeleiert hat wird sicherlich noch einige (chaotische) zeit vergehen. anderesseits deutet das aktuelle geschehen in testing darauf hin dass dort bereits hart gearbeitet wird.

[MustrumRidcully]

nochmal ein dickes danke für die detaillierten infos. ich werd mich auf release.debian.org mal einlesen...