---

Hej

Er der nogen med lidt mere forstand på Debian teamets arbejdsgange der
kan forklare hvorfor lyx og k3b pakker er forsvundet fra testing?
http://bjorn.haxx.se/debian/testing.pl?package=lyx og
http://bjorn.haxx.se/debian/testing.pl?package=k3b giver en god
forklaring på hvorfor de ikke bliver pushet fra unstable til testing.

Men hvorfor er de gamle versioner forsvundet fra testing?

K3b fik jeg installeret ved at lave en delvis upgrade til unstable. Men
lyx havde en dependency fejl jeg ikke gad og bøvle med (havde ssh adgang
til en anden maskine med lyx installeret...)

Venlige jule hilsner
Mads

---

Mads <mads@iname.com> writes:

> http://bjorn.haxx.se/debian/testing.pl?package=lyx og
> http://bjorn.haxx.se/debian/testing.pl?package=k3b giver en god
> forklaring på hvorfor de ikke bliver pushet fra unstable til testing.
>
> Men hvorfor er de gamle versioner forsvundet fra testing?

Se på pakkken arts. Hvis man skubber arts fra unstable til testing er
der 153 pakker der bliver umulige at installlere i testing. arts kan
ikke blive skubbet ned i testing så længe det vil gøre at der er andre
pakker der ikke kan installeres i testing.

Det kan løses på to måder:

- man gør en ny pakke klar til at blive skubbet ind i testing
samtidigt med arts

- man fjerner pakken fra testing så den ikke bliver uninstallable

I langt de fleste tilfælde vil man prøve at gøre det første. Hvis det
tager for lang tid og der er tale om en central pakke, vil det genere
udviklingen af testing og man vil derfor ty til den anden løsning.

Det er sandsynligvis det der er sket for k3b. Hvis du ser på den så er
den lige uploadet til unstable (0 dage gamel) og kan derfor tidligst
flyttes til testing om 10 dage. arts er derimod 23 dage gammel og en
lang række af pakkkerne der skal ind samtidigt med arts er også
omkring de 20 dage gammel.

Vedligeholderne af testing har derfor sikkert sagt at nu er det
vigtigt at arts bliver skubbet ned i testing, derfor bliver
forhindringer fjernet. Derfor bliver k3b fjernet fra testing og så må
vedligeholderen af k3b bare tage sig sammmen og få gjort k3b istand
til at blive installeret igen.


Vedrørende Lyx, så blev den fjernet tilbage i oktober af samme grund
for at kunne opgradere kde i testing. Lyx er så ikke blevet skubbet
ind i testing igen på grund af release-kritiske fejl.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333839

--
Peter Makholm | You know what the chain of command is?
peter@makholm.net | It's the chain I go get and beat you with 'til you
http://hacking.dk | understand who's in ruttin' command here.
| -- Jayne Cobb

---

On Tue, 20 Dec 2005 19:43:10 +0100, Peter Makholm wrote:


>
> Vedligeholderne af testing har derfor sikkert sagt at nu er det vigtigt at
> arts bliver skubbet ned i testing, derfor bliver forhindringer fjernet.
> Derfor bliver k3b fjernet fra testing og så må vedligeholderen af k3b
> bare tage sig sammmen og få gjort k3b istand til at blive installeret
> igen.
>
>
En helt generel betragtning, jeg har gjort, er, at opdateringen af KDE i
Debian (testing/unstable) synes at have lavere prioritet end Gnome. Har
jeg blot været uheldig de sidste par år, eller er mine få KDE-pakker
for perifere?

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> En helt generel betragtning, jeg har gjort, er, at opdateringen af KDE i
> Debian (testing/unstable) synes at have lavere prioritet end Gnome. Har
> jeg blot været uheldig de sidste par år, eller er mine få KDE-pakker
> for perifere?

Min opfattelse er at det er væsentligt mere besværligt at håndtere KDE
end Gnome. Jeg har en vag ide om at kernen af KDE er mere monolitisk
end kernen af Gnome, hvilket vil give større problemer fordi flere
ting skal falde i hak samtidigt.

Desuden er KDE skrevet i C++, hvilket gør at KDE får glæden af
C++-transistions ud over kdelibs-transistions. Qt har vist også skabt
nogle specifikket problemer på et tidspunkt som Gnome-folkene ikke har
haft glæde af. Endelig har KDE haft større besvær med at vikle sig ud
af nogle problemer med libpng og libjpeg, om det er fordi KDE-folkene
har været mere uheldige eller fordi KDE i forvejen er mere komplekst
skal jeg ikke kunne sige.

Så jeg tror mere det er et spørgsmål om kompleksitet end om at KDE er
nedprioriteret i forhold til Gnome.

--
Peter Makholm | One thing you do is prevent good software from
peter@makholm.net | being written. Who can afford to do professional
http://hacking.dk | work for nothing?
| -- Bill Gates

---

On Tue, 20 Dec 2005 20:44:34 +0100, Peter Makholm wrote:

>
> Min opfattelse er at det er væsentligt mere besværligt at håndtere KDE
> end Gnome. Jeg har en vag ide om at kernen af KDE er mere monolitisk end
> kernen af Gnome, hvilket vil give større problemer fordi flere ting skal
> falde i hak samtidigt.
>
CORBA sikrer, at modulariteten er eksplicit, men svjv. er KDE også bygget
over deres egen orb -> DCOP

> Desuden er KDE skrevet i C++, hvilket gør at KDE får glæden af
> C++-transistions ud over kdelibs-transistions. Qt har vist også skabt
> nogle specifikket problemer på et tidspunkt som Gnome-folkene ikke har
> haft glæde af. Endelig har KDE haft større besvær med at vikle sig ud
> af nogle problemer med libpng og libjpeg, om det er fordi KDE-folkene
> har været mere uheldige eller fordi KDE i forvejen er mere komplekst
> skal jeg ikke kunne sige.
>
Kan du uddybe dette?

> Så jeg tror mere det er et spørgsmål om kompleksitet end om at KDE er
> nedprioriteret i forhold til Gnome.

Er dette ikke blot et udspring af, at den bagved liggende designfilosofi
er fundamentalt anderledes i KDE?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> On Tue, 20 Dec 2005 20:44:34 +0100, Peter Makholm wrote:
>
>>
>> Min opfattelse er at det er væsentligt mere besværligt at håndtere KDE
>> end Gnome. Jeg har en vag ide om at kernen af KDE er mere monolitisk end
>> kernen af Gnome, hvilket vil give større problemer fordi flere ting skal
>> falde i hak samtidigt.
>>
> CORBA sikrer, at modulariteten er eksplicit, men svjv. er KDE også bygget
> over deres egen orb -> DCOP

Ikke destro mindre er det min opfattelse at hele KDE-kernen ligger i
kdelibs mens gnome-kernen er fordelt ud over en lang række mindre
lib*-pakker. Det sidste gør de enkelte pakker mere stabile i forhold
til afhængigheder.

>> Desuden er KDE skrevet i C++, hvilket gør at KDE får glæden af
>> C++-transistions ud over kdelibs-transistions. Qt har vist også skabt
>> nogle specifikket problemer på et tidspunkt som Gnome-folkene ikke har
>> haft glæde af. Endelig har KDE haft større besvær med at vikle sig ud
>> af nogle problemer med libpng og libjpeg, om det er fordi KDE-folkene
>> har været mere uheldige eller fordi KDE i forvejen er mere komplekst
>> skal jeg ikke kunne sige.
>>
> Kan du uddybe dette?

Hvilken del? At KDE er skrevet i c++, at KDE afhænger af Qt eller at
der har været problemer med libpng og libjpeg som har ramt både Gnome
og KDE?

>
>> Så jeg tror mere det er et spørgsmål om kompleksitet end om at KDE er
>> nedprioriteret i forhold til Gnome.
>
> Er dette ikke blot et udspring af, at den bagved liggende designfilosofi
> er fundamentalt anderledes i KDE?

De fleste af ovenstående problemer bunder i forskelligt design. Jeg
har ikke betragtet at KDE-vedligeholderene skulle være mere
inkompetente end Gnome-vedligeholderne.

Jeg har dog lidt på fornemmelsen at Gnome-vedligeholderene har været
en smule hurtigere til at indse at der skal mere diciplin til at
arbejde med et testing-system frem for da vi bare havde unstable og
stable. Men i dag tror jeg at KDE-vedligeholderne er på fuld højde på
dette område.

--
Peter Makholm | 'Cause suicide is painless
peter@makholm.net | It brings on many changes
http://hacking.dk | And I can take or leave it if I please
| -- Suicide is painless

---

On Tue, 20 Dec 2005 21:35:16 +0100, Peter Makholm wrote:

>
> Ikke destro mindre er det min opfattelse at hele KDE-kernen ligger i
> kdelibs mens gnome-kernen er fordelt ud over en lang række mindre
> lib*-pakker. Det sidste gør de enkelte pakker mere stabile i forhold til
> afhængigheder.
>
Det er også min opfattelse. Den sidste show-stopper ved opgradering af
KDE er altid kdelibs.

>
> Hvilken del? At KDE er skrevet i c++, at KDE afhænger af Qt eller at
> der har været problemer med libpng og libjpeg som har ramt både Gnome
> og KDE?

Det var dette, jeg hentydede til: "hvilket gør at KDE får glæden af
C++-transistions ud over kdelibs-transistions"

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

>> Hvilken del? At KDE er skrevet i c++, at KDE afhænger af Qt eller at
>> der har været problemer med libpng og libjpeg som har ramt både Gnome
>> og KDE?
>
> Det var dette, jeg hentydede til: "hvilket gør at KDE får glæden af
> C++-transistions ud over kdelibs-transistions"

Ordet "glæden" var selvfølgelig ironisk ment.

Når en ny version af gcc ændrer i C++ ABI'et, så skal alle
afhængigheder i C++ kode genoversættes og skubbes ind i testing i den
rigtige rækkefølge. En operation der er en del mere kompleks end bare
at opgraderer testing-versionen af KDE i sig selv.

Med da KDE er skrevet i C++ bliver KDE også viklet ind i denne
"opgradering" ud over de opgraderinger ændringer i kdelibs giver
alene.

--
Peter Makholm | What if:
peter@makholm.net | IBM bought Xenix from Microsoft instead of buying
http://hacking.dk | DOS?

---

On Tue, 20 Dec 2005 22:48:43 +0100, Peter Makholm wrote:

>
> Når en ny version af gcc ændrer i C++ ABI'et, så skal alle
> afhængigheder i C++ kode genoversættes og skubbes ind i testing i den
> rigtige rækkefølge. En operation der er en del mere kompleks end bare at
> opgraderer testing-versionen af KDE i sig selv.
>
Åh ja, hvornår mon denne ændringslyst i C++ ABI'et får en ende. Ikke
sådan at forstå, at jeg går tilbage til C, men det er nu en
tilfredsstillelse i sig selv, at man stadigvæk kan oversætte sin
sourcekode skrevet i det forrige årtusinde med seneste version af GCC:-\

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

On 2005-12-20, Michael Rasmussen <mir@miras.org> wrote:
> Åh ja, hvornår mon denne ændringslyst i C++ ABI'et får en ende. Ikke

For en tid, så skulle det være ved at være overstået.

Men det har krævet nogle kampe rundt omkring.

Og nu har debians kdeteam ikke lige så meget at gøre med k3b - det er
ikke et program fra kde, men et program skrevet til kde.

(forresten - der er et interview med debians kdeteam lige offentliggjort
et sted hvis det har interesse)

Jeg har fulgt en del med i dette - dels da jeg vedligeholder det
kde-relaterede program kommando i debian, dels da jeg vedligeholder en
samling .deb-filer der bruges sammen med kde. (styles/windecos ...)

/Sune

---

Peter Makholm wrote:
> Mads <mads@iname.com> writes:
>
>
>>http://bjorn.haxx.se/debian/testing.pl?package=lyx og
>>http://bjorn.haxx.se/debian/testing.pl?package=k3b giver en god
>>forklaring på hvorfor de ikke bliver pushet fra unstable til testing.
>>
>>Men hvorfor er de gamle versioner forsvundet fra testing?
>
> [snip god forklaing]
>
Tak for den gode forklaring.

Venlig hilsen
Mads

---

Michael Rasmussen <mir@miras.org> writes:

> Åh ja, hvornår mon denne ændringslyst i C++ ABI'et får en ende. Ikke
> sådan at forstå, at jeg går tilbage til C, men det er nu en
> tilfredsstillelse i sig selv, at man stadigvæk kan oversætte sin
> sourcekode skrevet i det forrige årtusinde med seneste version af GCC:-\

Nu skal du ikke blande en bedre overholdelse af C++ standarden sammen
med et stadigt ændrende ABI sammen. Man kan sagtens ændre C++ ABI'et
uden det får gcc til at være en mere korrekt C++ oversætter.

--
Peter Makholm | Emacs is the only modern general-purpose
peter@makholm.net | operating system that doesn't multitask
http://hacking.dk |