Author Topic: [DE] KDE-Next Repository - Ergänzungen (Read 17009 times)

agaida · « **Reply #15 on:** 2012/02/29, 16:17:53 »

KDE packen ist recht einfach und dauert auch gar nicht lange. Die Jungs bei Arch machen es vor. Die Kunst liegt darin, dass wir das Rad neu erfinden müssten. Das nutzt keiner Seite.

ralul · « **Reply #16 on:** 2012/02/29, 16:29:09 »

@agaida, Du irrst Dich hier wahrscheinlich.
Der Grund, dass es kein neueres Kde-4.8 und vorher schon kein Kde-4.7.4 gibt in Debian unstable sind die Libs, die wahrscheinlich von den Universitäten kommen, im Scientific Bereich. So habe ich die Mailingliste mit meinem kleinen English jedenfalls verstanden.

Wenn ich Recht habe, dass der Kde Stau bei Debian an den Sponsoren hängt - Sponsoren hier gemeint als Organisationen, die Entwickler abstellen, zB den jetzigen Debian Leader - dann könnte es sogar sein, dass sich Debian Maintainer, die Kde pushen wollen, für ein solches Projekt interessieren könnten: Eine Kde Spielwiese für reine Desktop Nutzer ...

Also, ich könnte mir mindestens vorstellen, dass wir sehr guten Support kriegen würden für solch eine Anstrengung in den entsprechenden Debian IRC Channeln, denn unser Projekt ist ja durch Devil als sehr Debian treu bekannt dort.

[edit] gerade Deinen Beitrag gesehen: "Rad neu erfinden"
Wieso, wir könnten die git-Repos der Debian Kde Maintainer plündern und nur eben für Kde-4.8 anpassen.

ralul · « **Reply #17 on:** 2012/02/29, 16:39:49 »

Einen problematischen Bereich für ein eigenes siduction Kde sehe ich nur:

Die Kdepim Nutzung
Eine Transition vom alten ins neuere Kdepim wäre sehr verantwortungsvoll und Risiko reich, weil wir mit wertvollen Nutzerdaten hantieren, die kaputt gehen könnten. Eine einfachst Lösung wäre zB eine Bedingung:
!Kmail
Da hätten dann Leute, wie Holgerw das Nachsehen und sauer

Wenn wir kde in einem extra Repo anbieten, könnten Kmail User halt später dazu kommen, wenn auch der kdepim Bereich getestet ist ....

Nebenbei:
Ein eigenes Kde Repo würde uns auch unabhängig machen von dem bevorstehenden Big-Freeze ähnlich wie beim Linux Kernel.

agaida · « **Reply #18 on:** 2012/02/29, 17:00:43 »

Ein anderer Vorschlag: Wir lassen es alles so, wie es ist und warten halt ab. Wir haben uns dazu entschlossen (ganz zufällig natürlich) sid als Basis zu nehmen. Damit haben wir auch den "debian way" übernommen: Abwarten und Tee trinken. Und wenn der mal knapp wird, dann einfach neuen kaufen.

Die Schwierigkeiten mit KDEPim kann ich zumindest nicht nachvollziehen, andere Distributionen auch nicht. Wenn in einer Software Fehler sind, dann setzt man, so möglich, alles daran, dass die Fehler gefixt werden. Der debian-way ist da anders: Laut weinen und versuchen, längst verrottete tote Pferde einzubauen. Vielleicht sehe ich das auch nur ein wenig zu locker. KDE 4.8 ist ja schon eine Weile releast, pünktlich zu KDE 4.9 or whatever wird dann KDE 4.8 in Sid erscheinen. Was solls.

devil · « **Reply #19 on:** 2012/02/29, 17:54:30 »

Nicht nur der Aufwand, es ist auch nicht ganz so trivial wie einfach mal ein Debian-Paket zu bauen. Das können wir derzeit und absehbar nicht stemmen.

greetz
devil

ReinerS · « **Reply #20 on:** 2012/02/29, 18:09:21 »

Hm, wir sind ja bei kdenext schon auf "experimental".

Auch wenn ich sehr dafür bin dass auch neuere Pakete die ewig in Debian hängenbleiben jetzt , wie mit "kdenext", angeboten werden so halte ich es ebenfalls vom Aufwand nicht wirklich machbar dass jeder sein neues Lieblingspaket ins Repo bekommt.
Da blickt dann nach ner Weile keiner mehr durch diesen Distro-Mix wirklich durch.

Wenn man halt wirklich dringend ein spezielles "Feature" einer Software braucht muss man es sich halt doch selbst (z.B. aus testing, experimental oder sogar incoming) besorgen und auf eigene Verantwortung installieren oder gegebenenfalls sogar selbst kompilieren.

So mach ichs bisher und ich weiss auch dann immer wer für den daraus entstehenden Unfug verantwortlich ist

Meine Meinung dazu.

Grüße

Reiner

agaida · « **Reply #21 on:** 2012/02/29, 18:22:35 »

@RainerS: In diesem Fall ist "experimental" ausentwickelt. Die Jungens warten nur noch auf einen Slot und den ein oder anderen Blocker. Oder lassen es ganz, wenn die Blocker für 4.8 weg sind, was wesentlich sinnvoller wäre. Von daher ist experimental != experimental und der Schritt zu 4.7.4 auch auf ISO war zu vertreten.

Ich bin wirklich kein Kind von Traurigkeit, was so was angeht. Allerdings stellt sich wirklich die reine Sinnfrage. Privat muss ich sagen, dass KDE 4.8 eine hübsche Sache ist, ich benutze es gerne, wie auch 4.7.4 - nur ich sehe den absoluten Zwang zum Umstieg nicht wirklich. Wenn es mal da ist, werde ich mich freuen.

Diese Versionitis geht mir so oder so ein wenig auf den Sack, größtenteils merke ich nicht einmal an den Funktionen, mit welcher Version ich arbeite. Beste Beispiele sind da Chromium oder aber Firefox, wo ich schon gar nicht mehr auf die Nummern schaue. Ich bin nur ab und zu mal etwas erstaunt, wie sich die Zahlen weiterentwickeln ...

ralul · « **Reply #22 on:** 2012/02/29, 18:22:54 »

agaida sagte: "Wir lassen es alles so, wie es ist und warten halt ab."

Da können wir halt wirklich _lange_ warten im Fall Kde: Es ist geplant "vielleicht" Kde-4.7.4 ins nächste Debian stable zu bekommen. Das würde heissen, dass sich mindestens ein Jahr lang nichts tun wird!

agaida · « **Reply #23 on:** 2012/02/29, 18:39:25 »

@ralul: Du bist eigentlich schon lange genug dabei, um zu wissen, wie es läuft: Richtig geraten - 4.7.4 geht nach sid, irgendwann - und irgendwann wird dann 4.8 in experimental erscheinen. Ist doch klasse. Und wenn die Pakete in ihrer Gesamtheit so stabil sind, dass wir die ohne schlechtes Gewissen auf unsere User loslassen können, dann werden wir das nach reiflicher Überlegung tun.

ralul · « **Reply #24 on:** 2012/02/29, 18:51:46 »

Hmm, dann bin ich falsch in meinem Impetus: Weil in einer Mailingliste gesagt wurde, dass das Releaseziel 4.7.4 ist, und weil ich weiss, dass das für Debian-sid ein Jahr lang Stillstand heisst, bin ich davon ausgegangen, dass die Debian Maintainer kein Interesse haben würden Kde-4.8 zu bauen.

Woher weisst du, dass Kde-4.8 nach experimental kommen wird?

agaida · « **Reply #25 on:** 2012/02/29, 19:18:50 »

In unserer schnellebigen Zeit kommen Mailinglisten gleich nach snailmail. Und da auf 4.7.4 eigentlich kaum was passiert ist in den letzten Wochen (die Paketänderungen halten sich in sehr eng definierten Grenzen) und das qt-kde-Team eifrig arbeitet, gehe ich davon aus, dass die in den letzten Wochen nicht untätig waren.Nebenbei tauscht man so die eine oder andere Zeile mit Entwicklern, die grade am packen sind.

Daraus habe ich einfach mal geschlussfolgert, dass die Jungs was für eine Transition haben, wenn sie einen Slot bekommen und die Blocker weg sind. So ganz nebenbei unterhält man sich auch ab und zu mal mit diesem und jenem ... Und wir reden hier ja wirklich von experimental und sid. Ob 4.8 in stable landet, ist mir so was von Wurst, das kann sich keiner vorstellen. Eine DE in stable ist so oder so kurz nach dem Erscheinen für unsere Zielgruppe einfach nur obsolet und irrelevant.

EDIT: Und dass 4.8 in experimental aufschlagen wird, ist so sicher wie das Amen in der Kirche. Im doppelten Sinne. Man weiss, dass es kommen wird, wenn auch nicht genau wann. Und auch in beiden Fällen: Viel zu spät!

holgerw · « **Reply #26 on:** 2012/03/01, 06:37:34 »

Hallo Alf,

ein extra Snapshot Repo wäre sicher ein zusätzlicher Luxus, aber ehrlich gesagt ist es doch nicht allzu schwer, gerade bei digikam sich die passenden 5 Pakete aus den Snapshots herunter zu laden und mit dpkg zu installieren.

Dass nur wenige Maintainer für Blockaden beim KDE Packen des KDE Debian Teams verantwortlich sind, macht mich nun doch sauer. Für den ambitionierten Anwender ist es nicht nachvollziehbar, dass unter einem nicht rollenden Release wie OpenSUSE quasi parallel zur Arbeit des KDE Entwicklerteams ein aktuelles OpenSUSE Community KDE Repo gepflegt wird, die bauen das einfach mal so und es funktioniert und bei Debian Sid als rollendem Release geht es nicht, weil einige Maintainer nicht daran interessiert sind, zeitnah den Nutzern das zu bieten, was die Projektgruppen freier Software liefern.
Damit meine ich NICHT siduction oder das KDE Debian Team, die leiden darunter ja auch, wie ich an anderer Stelle in einem Beitrag von Devil zum Wert von KDE in Debian gelesen habe.

Viele Grüße,
Holger

devil · « **Reply #27 on:** 2012/03/01, 08:19:54 »

Einen kleinen Fortschritt gibs zu vermelden. Die libarchive Transition ist fast beendet.
http://release.debian.org/transitions/html/libarchive.html

greetz
devil

agaida · « **Reply #28 on:** 2012/03/01, 10:54:36 »

@holgerw: snaps sollte eigentlich keinen zusätzlichen Luxus bieten, sondern den Prozess einfach sauber machen. Wenn Du auf die Liste der geblockten KDE-Pakete schaust, wirst Du verstehen, was ich meine (digikam, kipiplugins sind momentan auf der Liste, die rot ist und gestern wieder ein Stück kleiner wurde). Wenn also digikam regulär gebaut wird, würde das mit Snaps überschneidungen geben. Nicht schön.

Auch wenn ich den Frust über debian nachvollziehen kann - ich haue ja auch bei jeder passenden und auch unpassenden Gelegenheit auf den Buben rum - Du machst da einen kleinen Denkfehler. sid und testing sind *keine* rollenden Distributionen. Auch wenn einige Leute das gerne so sagen und einige Merkmale einer rollenden Distribution durchaus gegeben sind.

Diese Diskussion kommt immer zu Freezes wieder auf: In kurzen Worten - wie nennt man eine rollende Distribution, wenn sie mal nicht rollt. Laut debian-Definition sind Sid und Testing Entwicklungszweige, die dazu dienen, das nächste Stable zu basteln. Das das Zeug den Namen nicht ändert und in Zeiten in denen nicht Eiszeit angesagt ist, auch ganz gut rollt, ist ein netter Nebeneffekt. Mehr nicht. Deshalb geisterte auc die Idee von CUT vor einiger Zeit duch Mailing-Listen. Das unterbrechungsfrei nutzbare Testing würde einer echten rollenden Distribution wesentlich näher kommen, als der bisherige Stand.

bluelupo · « **Reply #29 on:** 2012/03/01, 12:35:36 »

Quote from: "agaida"

[...]
Diese Diskussion kommt immer zu Freezes wieder auf: In kurzen Worten - wie nennt man eine rollende Distribution, wenn sie mal nicht rollt. Laut debian-Definition sind Sid und Testing Entwicklungszweige, die dazu dienen, das nächste Stable zu basteln. Das das Zeug den Namen nicht ändert und in Zeiten in denen nicht Eiszeit angesagt ist, auch ganz gut rollt, ist ein netter Nebeneffekt. Mehr nicht. Deshalb geisterte auc die Idee von CUT vor einiger Zeit duch Mailing-Listen. Das unterbrechungsfrei nutzbare Testing würde einer echten rollenden Distribution wesentlich näher kommen, als der bisherige Stand.

..wie ist denn der aktuelle Stand von CUT, ohne jetzt ellenlange englischsprachige Debianseiten lesen zu müssen? Wäre halt schön wenn ein "echtes RR" in Debian in naher Zukunft Wirklichkeit werden würde ***träum***