Wofür ist testing gut?
Kai Großjohann
benutzen möchte. Und es kam dabei eine Tabelle raus. Und ich kann
mich nicht daran erinnern, dass testing in dieser Tabelle vorgekommen
wäre. Entweder man empfahl den Leuten stable (ggfs. mit
Anpassungen), oder man empfahl ihnen unstable oder gar experimental.
Also, wofür ist testing gut?
(Nicht provozierend gemeint, ich will bloß was lernen.)
--
A turnip curses Elvis
--
Häufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Marcus Frings
> Hier war ja neulich ein Thread darüber, wer welche Version von Debian
> benutzen möchte. Und es kam dabei eine Tabelle raus. Und ich kann
> mich nicht daran erinnern, dass testing in dieser Tabelle vorgekommen
> wäre. Entweder man empfahl den Leuten stable (ggfs. mit
> Anpassungen), oder man empfahl ihnen unstable oder gar experimental.
> Also, wofür ist testing gut?
Sid (also unstable) ist im Grunde für Debian _Entwickler_ gedacht, wo
sie ihre neuen Pakete hochladen können und die dann vorrangig andere
Debian Entwickler testen sollen. Sind dann in den Paketen keine wirklich
_kritischen_ Fehler mehr enthalten, rutschen diese nach einer mehr oder
weniger langen Zeit in Testing (zur Zeit und wohl auch für einige
weitere Monate: Sarge) rein, wo sie dann von der breiteren
Allgemeinheit getestet werden sollen. Ist die Allgemeinheit irgendwann
zufrieden mit Testing, wird ein Freeze gemacht und irgendwann wird
Testing/Sarge zu Stable/Sarge erklärt und es wird ein neuer Testingzweig
mit neuem Namen kommen.
Warum Testing _zur Zeit_ nicht empfohlen wird, hängt mit dem Grund der
momentanen elementaren Änderungen in Sid zusammen. Dort wird gerade auf
libc6 2.3.x umgestellt. libc6 ist aber noch nicht in den Entwickleraugen
hinreichend "Debian-stabil", weswegen die neue libc6 auch nicht in
Testing reinrutscht. Weil viele (okay, fast alle :-) Pakete irgendwie
von libc6 abhängen, kommen also auch keine neuen Sid-Pakete in Testing
rein, was zur Folge hat, daß Testing gegenwärtig _sehr_ viele
Sicherheitslücken und Bugs besitzt, wohingegen diese eigentlich schon
längst in Sid gefixt sind, aber wegen obigem Problem nicht nach Testing
wandern.
Testing zu verwenden, ist also im Grunde schon sinnvoll, wenn man die
goldene Mitte zwischen stable (aber veraltet) und Bleeding Edge (aber
evtl. mit kritischen Bugs) haben will - nur will man das _im Moment_
nicht! :-)
Ich hoffe, Deine Fragen geklärt zu haben.
Gruß,
Marcus
--
PGP Keysigning Party am Dienstag, den 04.02.2003, von 19:15 - 22:00 Uhr im
Raum 201 des Gebäudes des Philosophischen Instituts der RWTH Aachen,
Eilfschornsteinstraße 16. Anmeldung und weitere Infos hier:
http://www.ccac.rwth-aachen.de/keysigning_party/
Norbert Tretkowski
> Also, wofür ist testing gut?
Fuer Leute denen stable zu alt, und unstable zu ungetestet ist.
Adrian Bunk
>...
> Warum Testing _zur Zeit_ nicht empfohlen wird, hängt mit dem Grund der
> momentanen elementaren Änderungen in Sid zusammen. Dort wird gerade auf
> libc6 2.3.x umgestellt. libc6 ist aber noch nicht in den Entwickleraugen
> hinreichend "Debian-stabil", weswegen die neue libc6 auch nicht in
> Testing reinrutscht. Weil viele (okay, fast alle :-) Pakete irgendwie
> von libc6 abhängen, kommen also auch keine neuen Sid-Pakete in Testing
> rein, was zur Folge hat, daß Testing gegenwärtig _sehr_ viele
> Sicherheitslücken und Bugs besitzt, wohingegen diese eigentlich schon
> längst in Sid gefixt sind, aber wegen obigem Problem nicht nach Testing
> wandern.
>
> Testing zu verwenden, ist also im Grunde schon sinnvoll, wenn man die
> goldene Mitte zwischen stable (aber veraltet) und Bleeding Edge (aber
> evtl. mit kritischen Bugs) haben will - nur will man das _im Moment_
> nicht! :-)
>...
testing hat auch ansonsten so seine Nachteile:
- deutlich mehr Bugs als stable
- bei Sicherheitsupdates kann es jederzeit passieren dass ein fuer dich
wichtige Fix mehrere Monate braucht bis er in testing landet
- "moving target": jeden Tag andere Pakete mit neuen Problemen
Auf Produktivsystemen ist testing eigentlich _zu keiner Zeit_ zu
empfehlen.
testing ist eigentlich nur gut fuer:
- die Vorbereitung eines Releases (ich persoenlich faende es dabei
eigentlich eher sinnvoller wie frueher unstable zu freezen aber das
ist eine andere Sache)
- Leute wie mich die eigentlich unstable verwenden wuerden aber dabei
nicht jeden einzelnen neuen Bug abbekommen moechten
Dass immer mehr Leute dazu uebergehen testing zu verwenden liegt daran
dass Debian 3.1 meiner persoenlichen Einschaetzung nach wohl fruehestens
2004 kommen wird, es aber schon heute oft nichttrivial ist einen neuen
Rechner zu finden dessen Hardware von den etwas angestaubten Paketen in
stable unterstuetzt wird.
> Gruß,
> Marcus
Gruss
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk
und denen es nichts ausmacht wenn sie Security-Fixes erst mit ueber
einem Vierteljahr Verspaetung bekommen (von den Fixes aus den letzten
70 Debian Security Advisories ist vermutlich noch kein einziger in
testing)...
Gruss
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Kai Großjohann
> Dass immer mehr Leute dazu uebergehen testing zu verwenden liegt daran
> dass Debian 3.1 meiner persoenlichen Einschaetzung nach wohl fruehestens
> 2004 kommen wird, es aber schon heute oft nichttrivial ist einen neuen
> Rechner zu finden dessen Hardware von den etwas angestaubten Paketen in
> stable unterstuetzt wird.
Und was macht man da am besten?
--
A turnip curses Elvis
Jakob Lenfers
> Hier war ja neulich ein Thread darüber, wer welche Version von Debian
> benutzen möchte. Und es kam dabei eine Tabelle raus. Und ich kann
> mich nicht daran erinnern, dass testing in dieser Tabelle vorgekommen
> wäre. Entweder man empfahl den Leuten stable (ggfs. mit
> Anpassungen), oder man empfahl ihnen unstable oder gar experimental.
Ich finde es ist eine schöne Zwischenstufe. Ich habe ca. ein Jahr lang
bevor Woody stable wurde Woody als testing benutzt. (Auf dem Desktop,
nicht auf dem Heim-Server) Und ich hatte eigentlich bis auf einmal nie
Probleme. Es ist neuer aber nicht so gefährlich wie unstable. Leider
gibts keine Security-Fixes...
Jakob
--
(setq gnus-posting-styles '(
((message-mail-p)
(signature "Nö"))
))
Eduard Bloch
Jakob Lenfers schrieb am Sunday, den 02. February 2003:
> > mich nicht daran erinnern, dass testing in dieser Tabelle vorgekommen
> > wäre. Entweder man empfahl den Leuten stable (ggfs. mit
> > Anpassungen), oder man empfahl ihnen unstable oder gar experimental.
>
> Ich finde es ist eine schöne Zwischenstufe. Ich habe ca. ein Jahr lang
> bevor Woody stable wurde Woody als testing benutzt. (Auf dem Desktop,
> nicht auf dem Heim-Server) Und ich hatte eigentlich bis auf einmal nie
> Probleme. Es ist neuer aber nicht so gefährlich wie unstable. Leider
^^^^^^^^^^^^^^^^^^^
> gibts keine Security-Fixes...
^^^^^^^^^^^^^^^^^^^^^^^^^^
Das ist nur die Spitze des Eisberges. Deine "gute Erfahrungen" kann man
nur während des Freezes machen, und das ist auch der einzige Zeitraum,
wo Testing halbwegs sinnvoll sein _kann_, denn da haben die Maintainer
extrem viel Rücksicht auf Zusammenspiel von Sid und Woody-Paketen machen
müssen. Aber es gab diverse Sicherheitslücken und der "transparente"
Freeze-Status war z.B. für die Entwicklung der Boot-Floppies ein ständiger
Spielverderber.
Was bring Testing heute einem? Gar nichts. Die neuere Versionen kommen
praktisch nicht rein wegen binären Abhängigkeiten von Unstable-Paketen.
Will man etwas installieren, muss man gleich das halbe Unstable
nachziehen. Und ist Testing wirklich frei von Bugs? Eine
Wunschvorstellung. Die Security-Fixes wurden schon erwähnt. Und viele
Fixes der Upstream-Maintainer kommen auch nicht in Testing an, seit
Monaten nicht mehr. Mit etwas weniger Glück hat man in Sarge eine
"linke" Version des Pakets, die vielleicht keinen RC-Bug in den ersten
5-10 Tagen gezeigt hat, aber inzwischen schon 10 mindestens so hässliche
Probleme aufweist, die in Unstable schon seit Monaten gefixt wurden -
aber die Testing-User müssen sich damit immer noch herumplagen. Und da
kommt so schnell _kein_ Update dank des kranken Synchronisationskonzepts
von Testing.
So, und wenn ich jetzt zu viel Zeit haette, würde ich endlich das
Debian-Working-System implementieren, das all diese aus Not entstandene
Sachen wie Adrians Backports "legalisieren" würde.
Gruss/Regards,
Eduard.
--
Der Schuldirektor ruft Fritzchen herbei.
"Da sind Farbe und Pinsel, geh mal die Fenster streichen."
Eine halbe Stunde später kommt Fritzchen zurück.
"Soll ich auch die Rahmen streichen?"
Norbert Tretkowski
> Was bring Testing heute einem? Gar nichts. Die neuere Versionen
> kommen praktisch nicht rein wegen binären Abhängigkeiten von
> Unstable-Paketen.
Das liegt aber daran, das die meisten Maintainer ihre Packages auf
unstable bauen. Wuerden sie sie (wo es eben moeglich ist) auf testing
bauen, haette man das Problem nicht in dem Umfang.
> So, und wenn ich jetzt zu viel Zeit haette, würde ich endlich das
> Debian-Working-System implementieren, das all diese aus Not
> entstandene Sachen wie Adrians Backports "legalisieren" würde.
Apropos Backports...
http://people.debian.org/~nobse/debian/woody/backported/
Gruss, Norbert
Kai Großjohann
> So, und wenn ich jetzt zu viel Zeit haette, würde ich endlich das
> Debian-Working-System implementieren, das all diese aus Not entstandene
> Sachen wie Adrians Backports "legalisieren" würde.
Was ist das Debian-Working-System?
Kai Großjohann
> Apropos Backports...
<AOL> Gibt es ein Howto dazu? Ich habe das Paket maint-guide
installiert und die Postscript-Fassung gelesen, aber dort wird ja
doch eher kurz von dem Programm uupdate gesprochen. Vielleicht gibt
es ja ein Dokument, das auf mögliche Probleme eingeht? Z.B. möchte
man vielleicht, dass das offizielle Paket installiert wird, wenn das
neuer ist als das selbst erstellte... Und geht man für Backports
besser von dem Stable-Paket aus und benutzt uupdate, um das mit den
neuen Sourcen zu verheiraten, oder geht man besser vom Unstable-Paket
aus und dreht an den Build-Dependencies? Oder vielleicht noch anders?
Rene Engelhard
Norbert Tretkowski wrote:
> * Eduard Bloch <e...@gmx.de> wrote:
> > Was bring Testing heute einem? Gar nichts. Die neuere Versionen
> > kommen praktisch nicht rein wegen binären Abhängigkeiten von
> > Unstable-Paketen.
>
> Das liegt aber daran, das die meisten Maintainer ihre Packages auf
> unstable bauen. Wuerden sie sie (wo es eben moeglich ist) auf testing
> bauen, haette man das Problem nicht in dem Umfang.
Das ist ebenfalls Humbug. Wenn ich als Maintainer mein Paket auf
testing bauen würde, würden die Autobuilder für die anderen
Architekturen das Paket auf unstable basierend bauen, was das
Source-Paket und alle Architekturen zurückalten kann, wenn in unstable
eine wichtige Lib (wie momentan die glibc) kaputt ist.
Und wenn man alle Programme auch auf den Autobuildern bauen würde,
dann hat man das Problem, das die Libraries in unstable (z.B. neue
glibc) nicht genügend getestet werden (es kam z.B. vor, das Programme
mit der neuen glibc nicht mehr liefen; deswegen ja die ganzen
Probleme)
Und bei größeren Umstellungen wie bei der g++-3.2 transition ist das
auch nicht gerade ein guter Weg...
Grüße
Rene
--
.''`. Rene Engelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' re...@debian.org | GnuPG-Key ID: 248AEB73
`- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Eduard Bloch
Kai Großjohann schrieb am Sunday, den 02. February 2003:
> > So, und wenn ich jetzt zu viel Zeit haette, würde ich endlich das
> > Debian-Working-System implementieren, das all diese aus Not entstandene
> > Sachen wie Adrians Backports "legalisieren" würde.
>
> Was ist das Debian-Working-System?
http://www.debian.org/vote/2002/platforms/raphael#release1
Gruss/Regards,
Eduard.
--
Kleine Taten, die man ausführt, sind besser als große, die man plant.
Eduard Bloch
Norbert Tretkowski schrieb am Sunday, den 02. February 2003:
> > Was bring Testing heute einem? Gar nichts. Die neuere Versionen
> > kommen praktisch nicht rein wegen binären Abhängigkeiten von
> > Unstable-Paketen.
>
> Das liegt aber daran, das die meisten Maintainer ihre Packages auf
> unstable bauen. Wuerden sie sie (wo es eben moeglich ist) auf testing
> bauen, haette man das Problem nicht in dem Umfang.
Das liegt doch gar nicht in der Hand der Maintainer, die können entweder
alle Pakete einzeln auf jeder Arch bauen, oder noch Unstable uploaden.
Upload nach Testing (d.h. für Testing laufende Builder) geht nicht.
> > So, und wenn ich jetzt zu viel Zeit haette, würde ich endlich das
> > Debian-Working-System implementieren, das all diese aus Not
> > entstandene Sachen wie Adrians Backports "legalisieren" würde.
>
> Apropos Backports...
>
> http://people.debian.org/~nobse/debian/woody/backported/
www.apt-get.org wäre das Richtige dafür. BTW, was nimmst du für den
Aufbau der Pool-Struktur?
Gruss/Regards,
Eduard.
--
Wie man sein Kind nicht nennen sollte:
Wim Bledon
Kai Großjohann
> Kai Großjohann schrieb am Sunday, den 02. February 2003:
>
>> Was ist das Debian-Working-System?
>
> http://www.debian.org/vote/2002/platforms/raphael#release1
Das sieht sehr sinnvoll aus.
Norbert Tretkowski
Nicht das ich wuesste, hier tun es apt-get und dpkg-buildpackage.
> Z.B. möchte man vielleicht, dass das offizielle Paket installiert
> wird, wenn das neuer ist als das selbst erstellte...
Wenn man die Versionsnummer nicht anfasst, ist das eh der Fall.
> Und geht man für Backports besser von dem Stable-Paket aus und
> benutzt uupdate, um das mit den neuen Sourcen zu verheiraten, oder
> geht man besser vom Unstable-Paket aus und dreht an den
> Build-Dependencies?
Ich gehe vom Package aus unstable aus, und versuche (wo moeglich) die
Build-Depends zu erfuellen.
Norbert Tretkowski
> > Das liegt aber daran, das die meisten Maintainer ihre Packages auf
> > unstable bauen. Wuerden sie sie (wo es eben moeglich ist) auf
> > testing bauen, haette man das Problem nicht in dem Umfang.
>
> Das liegt doch gar nicht in der Hand der Maintainer, die können
> entweder alle Pakete einzeln auf jeder Arch bauen, oder noch
> Unstable uploaden. Upload nach Testing (d.h. für Testing laufende
> Builder) geht nicht.
Das man nicht nach Testing uploaden kann, ist mir bewusst. Ich baue
meine Packages nur nicht auf Unstable, sondern auf Testing. Dann kann
ich halbwegs sicher sein, das nicht durch eine kaputte Library in
Unstable auch mein Package unbenutzbar wird.
> > Apropos Backports...
> >
> > http://people.debian.org/~nobse/debian/woody/backported/
>
> www.apt-get.org wäre das Richtige dafür.
Die haben meine letzten beiden Submits bisher ignoriert.
> BTW, was nimmst du für den Aufbau der Pool-Struktur?
Naja, fuer die Pool Struktur fehlt ja jeweils noch ein Verzeichnis.
Ich mache das der Uebersichtlichkeit halber aber von Hand.
Norbert Tretkowski
> > > kommen praktisch nicht rein wegen binären Abhängigkeiten von
> > > Unstable-Paketen.
> >
> > unstable bauen. Wuerden sie sie (wo es eben moeglich ist) auf
> > testing bauen, haette man das Problem nicht in dem Umfang.
>
> testing bauen würde, würden die Autobuilder für die anderen
> Architekturen das Paket auf unstable basierend bauen, was das
> Source-Paket und alle Architekturen zurückalten kann, wenn in
> unstable eine wichtige Lib (wie momentan die glibc) kaputt ist.
Hmm, das hatte ich in der Tat nicht bedacht. Ich kann mich aber daran
erinnern, das es, kurz nach der Entscheidung zum testing Zweig, die
Empfehlung gab, die Packages auf testing zu bauen.
Adrian Bunk
>... Und geht man für Backports
> besser von dem Stable-Paket aus und benutzt uupdate, um das mit den
> neuen Sourcen zu verheiraten, oder geht man besser vom Unstable-Paket
> aus und dreht an den Build-Dependencies? Oder vielleicht noch anders?
Man geht normalerweise vom Paket in unstable (oder testing) aus.
Entweder die build dependencies lassen sich auf stable erfuellen oder
man muss anfangen sich das Paket genauer anzusehen. "uupdate" vom
Paket in stable aus duerfte in vielen Faellen deutlich schwieriger sein.
Gruss
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk
>...
> > Z.B. möchte man vielleicht, dass das offizielle Paket installiert
> > wird, wenn das neuer ist als das selbst erstellte...
>
> Wenn man die Versionsnummer nicht anfasst, ist das eh der Fall.
1. zwei verschiedene Pakete mit der gleichen Versionsnummer schaffen nur
Verwirrung
2. stell' dir vor du hast fuenf verschiedene sources.list Eintraege die
alle das gleiche Paket mit der gleichen Versionsnummer bieten, es ist
aber jedesmal ein anders kompiliertes Paket - das willst du nicht
wirklich
Gruss
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk
> Das man nicht nach Testing uploaden kann, ist mir bewusst. Ich baue
> meine Packages nur nicht auf Unstable, sondern auf Testing. Dann kann
> ich halbwegs sicher sein, das nicht durch eine kaputte Library in
> Unstable auch mein Package unbenutzbar wird.
>...
Wenn du deine Pakete auf testing baust und alle Autobuilder auf unstable
kann das schnell dazu fuehren dass es technisch unmoeglich wird dass
dein Paket jemals nach testing kommen kann weil testing sich evtl. nie
in einem Zustand befinden kann in dem dein Paket auf allen Architekturen
installierbar waere.
Gruss
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Andreas Metzler
> * Eduard Bloch <e...@gmx.de> wrote:
>> Was bring Testing heute einem? Gar nichts. Die neuere Versionen
>> kommen praktisch nicht rein wegen binären Abhängigkeiten von
>> Unstable-Paketen.
> Das liegt aber daran, das die meisten Maintainer ihre Packages auf
> unstable bauen. Wuerden sie sie (wo es eben moeglich ist) auf testing
> bauen, haette man das Problem nicht in dem Umfang.
[...]
Nicht die Maintainer sondernd die Build-Daemons baue die ueberwiegende
Zahl der Pakete, und die fahren sid (im Build-chroot). Wie man in
vielen Disussionen auf debian-devel nachlesen kann, ist das noetig
damit neue Versionen von Libraries halbwegs getestet (bzw. ueberhaupt)
nach testing wandern.
cu andreas
Adrian Bunk
> Hmm, das hatte ich in der Tat nicht bedacht. Ich kann mich aber daran
> erinnern, das es, kurz nach der Entscheidung zum testing Zweig, die
> Empfehlung gab, die Packages auf testing zu bauen.
Welcher Idiot hat denn diesen Schmarrn verzapft?
Stell dir z.B. vor:
testing:
Sourcepaket: foo
Binaerpaket: libfoo0
unstable:
Sourcepaket: foo
Binaerpaket: libfoo1
Dein Paket ist mit libfoo gelinkt.
Wenn du auf einer Architektur das Paket auf testing kompilierst hat es
dort eine Abhaengigkeit auf libfoo0.
Die Autobuilder kompilieren dein Paket auf allen anderen Architekturen
auf unstable wodurch es dort von libfoo1 abhaengt.
So wie testing funktioniert ist es unmoeglich dass libfoo0 und libfoo1
zu irgendeinem Zeitpunkt gleichzeitig in testing sind.
Nachdem dein Paket zu jedem beliebigen Zeitpunkt auf mindestens einer
Architektur in testing nicht installierbar waere werden es die
testing-Skripte nie zulassen dass die neue Version deines Pakets in
testing kommt.
Korollar:
Wenn dein Paket bereits in einer aelteren Version mit libfoo0 gelinkt in
testing ist verhinderst du damit auch dass die neuere Version von foo
jemals nach testing kommt.
Gruss
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Eduard Bloch
Norbert Tretkowski schrieb am Sunday, den 02. February 2003:
> > Das liegt doch gar nicht in der Hand der Maintainer, die können
> > entweder alle Pakete einzeln auf jeder Arch bauen, oder noch
> > Unstable uploaden. Upload nach Testing (d.h. für Testing laufende
> > Builder) geht nicht.
>
> Das man nicht nach Testing uploaden kann, ist mir bewusst. Ich baue
> meine Packages nur nicht auf Unstable, sondern auf Testing. Dann kann
Das ist eine Medaille mit zwei Seiten - FTBFS-Probleme, die durch
Unstable-Build-Umgebung entstehen, kriegst du nicht mit.
> ich halbwegs sicher sein, das nicht durch eine kaputte Library in
> Unstable auch mein Package unbenutzbar wird.
Aber nur für deine Arch, 10 andere kriegen die automatisch gebaute
Version - für Unstable.
> Die haben meine letzten beiden Submits bisher ignoriert.
>
> > BTW, was nimmst du für den Aufbau der Pool-Struktur?
>
> Naja, fuer die Pool Struktur fehlt ja jeweils noch ein Verzeichnis.
> Ich mache das der Uebersichtlichkeit halber aber von Hand.
A-Ha. Es gab ja einen langen Thread über private Pools, da wurden IIRC
auch brauchbare Verwaltungsskripte genannt.
Gruss/Regards,
Eduard.
--
Ist man in der Liebe und Freundschaft darin, so rechnet man ihr sogar
gewöhnliche Tugenden als Reize an - dem Unbekannten aber fordert man
sie ab ohne Dank.
-- Jean Paul
Rene Engelhard
> Hi,
>
> Norbert Tretkowski wrote:
> > * Eduard Bloch <e...@gmx.de> wrote:
> > > Was bring Testing heute einem? Gar nichts. Die neuere Versionen
> > > kommen praktisch nicht rein wegen binären Abhängigkeiten von
> > > Unstable-Paketen.
> >
> > Das liegt aber daran, das die meisten Maintainer ihre Packages auf
> > unstable bauen. Wuerden sie sie (wo es eben moeglich ist) auf testing
> > bauen, haette man das Problem nicht in dem Umfang.
>
> testing bauen würde, würden die Autobuilder für die anderen
> Architekturen das Paket auf unstable basierend bauen, was das
> Source-Paket und alle Architekturen zurückalten kann, wenn in unstable
> eine wichtige Lib (wie momentan die glibc) kaputt ist.
>
hier habe ich ein "auf testing basierend" vergessen...
Norbert Tretkowski
> auch brauchbare Verwaltungsskripte genannt.
Wenn ich mal zuviel Zeit hab...
Fuer die paar Packages tut das momentan noch ganz gut.
Norbert Tretkowski
> On Sun, Feb 02, 2003 at 10:02:57PM +0100, Norbert Tretkowski wrote:
> >...
> > > Z.B. möchte man vielleicht, dass das offizielle Paket installiert
> > > wird, wenn das neuer ist als das selbst erstellte...
> >
> > Wenn man die Versionsnummer nicht anfasst, ist das eh der Fall.
> >...
>
> 1. zwei verschiedene Pakete mit der gleichen Versionsnummer schaffen nur
> Verwirrung
> 2. stell' dir vor du hast fuenf verschiedene sources.list Eintraege die
> alle das gleiche Paket mit der gleichen Versionsnummer bieten, es ist
> aber jedesmal ein anders kompiliertes Paket - das willst du nicht
> wirklich
Ueberredet. Ich werde meinen Backports in Zukunft eine angepasste
Versionsnummer verpassen.
Sven Lauritzen
> Das ist nur die Spitze des Eisberges. Deine "gute Erfahrungen" kann man
> nur während des Freezes machen, und das ist auch der einzige Zeitraum,
Da kann ich nicht ganz folgen. Beim upgrade auf sarge hatte ich keine
Probleme.
> Was bring Testing heute einem? Gar nichts. Die neuere Versionen kommen
> praktisch nicht rein wegen binären Abhängigkeiten von Unstable-Paketen.
> Will man etwas installieren, muss man gleich das halbe Unstable
> nachziehen. Und ist Testing wirklich frei von Bugs?
Die Verwendung von Testing auf produktiven Servern im Internet ist
sicher als waghalsig zu bezeichnen. Auf Workstations im LAN ist das
Risiko eher in der moeglichen Zeitverschwendung zu sehen, sofern man
regelmaessig Backups von seinen Daten macht.
Ich finde die Worte fuer testing etwas hart, denn der Zweig hat durchaus
seinen Sinn, wenn auch mehr fuer die Entwickler als fuer den Benutzer.
Testing verloere seinen Sinn, naemlich sicherzustellen, dass die
zukuenftige stable moeglichst arm an Bugs ist, wenn es niemand benutzen
und Bugs berichten wuerde.
Daraus lasst sich folgender Rat ableiten: Je nach Risikobereitschaft,
Engagement, Erfahrung mit Debian und personlichen Beduerfnissen sollte
man frueher, spaeter oder gar nicht auf testing umsteigen. Ab dem
Zeitpunkt des Freezes ist es unerlaesslich, dass der Nutzerkreis nach
und nach groesser wird.
Zur Zeit ist es sicherlich so, da muss ich zustimmen, dass testing eher
sinnfrei vor sich hinvegetiert.
> So, und wenn ich jetzt zu viel Zeit haette, würde ich endlich das
> Debian-Working-System implementieren, das all diese aus Not entstandene
> Sachen wie Adrians Backports "legalisieren" würde.
"Das" Debian-Working-System? Ist da was tolles im FIFO?
Gruss
Sven
--
Sven Lauritzen
----------------------------------------------------------------
pub 1024D/95C9A892 sub 1024g/D30E490F
Fp 2FA9 FC9B 078C 5BC7 87DC 0B0D 2329 94F6 95C9 A892
----------------------------------------------------------------
Rene Engelhard
Adrian Bunk wrote:
> On Sun, Feb 02, 2003 at 09:28:14PM +0100, Kai Großjohann wrote:
>
> >... Und geht man für Backports
> > besser von dem Stable-Paket aus und benutzt uupdate, um das mit den
> > neuen Sourcen zu verheiraten, oder geht man besser vom Unstable-Paket
> > aus und dreht an den Build-Dependencies? Oder vielleicht noch anders?
>
> Man geht normalerweise vom Paket in unstable (oder testing) aus.
> Entweder die build dependencies lassen sich auf stable erfuellen oder
> man muss anfangen sich das Paket genauer anzusehen. "uupdate" vom
> Paket in stable aus duerfte in vielen Faellen deutlich schwieriger sein.
Außerdem benutzen viele Developer "alternative" Build-Systeme wie DBS,
dpatch und CBS. Zumindest bei DBS kommst Du mit uupdate nicht weit und
bei dpatch musst Du auch nachbearbeiten
(alle -- bis auf eins und das wird umgestellt wenn eine neue
Upstream-Version kommt -- "meine" Pakete sind DBS)
Kai Weber
> Hier habe ich "Hallo!" vergessen ;-)!
Ähem. Das war ein typischer Fall von http://learn.to/quote und sollte
nicht wieder vorkommen! Bitte!
--
» kai....@glorybox.de
http://www.glorybox.de
Andreas Metzler
[...]
> Außerdem benutzen viele Developer "alternative" Build-Systeme wie DBS,
> dpatch und CBS. Zumindest bei DBS kommst Du mit uupdate nicht weit und
> bei dpatch musst Du auch nachbearbeiten
> (alle -- bis auf eins und das wird umgestellt wenn eine neue
> Upstream-Version kommt -- "meine" Pakete sind DBS)
Hallo!
Hast du dir dpatch mal genauer angeschaut? Imho ist das sehr oft die
bessere Wahl, weil es weit weniger intrusiv als dbs ist. Man
erspart sich z.B. das Umpacken der Originalsourcen, teilweise ist es
auch flexibler. Dafuer muss man ein echtes "clean" und nicht nur
rm -rf basteln.
cu andreas
Kai Großjohann
> On Sun, Feb 02, 2003 at 09:28:14PM +0100, Kai Großjohann wrote:
>
>>... Und geht man für Backports
>> besser von dem Stable-Paket aus und benutzt uupdate, um das mit den
>> neuen Sourcen zu verheiraten, oder geht man besser vom Unstable-Paket
>> aus und dreht an den Build-Dependencies? Oder vielleicht noch anders?
>
> Man geht normalerweise vom Paket in unstable (oder testing) aus.
> Entweder die build dependencies lassen sich auf stable erfuellen
Du meinst "sind sowieso erfüllt"?
> oder man muss anfangen sich das Paket genauer anzusehen.
Also, man dreht die Build-Dependencies runter, wenn die Sourcen auch
mit der alten Version klar kommen, oder man baut auch die neue
Library aus den Sourcen?
> "uupdate" vom Paket in stable aus duerfte in vielen Faellen deutlich
> schwieriger sein.
Warum? (Ich will's nicht anzweifeln, sondern nur verstehen.)
Ich als Dummuser hätte jetzt angenommen, dass das debian/-Verzeichnis
für Stable gut getestet ist, und dass ich mir mit einem Update auf
die neuen Sourcen eben nur neue Sourcen, nicht aber neue Bugs im
debian/-Verzeichnis, einhandle.
Das geht natürlich davon aus, dass man die neue Version der
Upstream-Sourcen genauso compiliert wie die alten, d.h. an der
./configure-Mimik oder der xmkmf-Mimik hat sich nix geändert. Es ist
logisch, dass ich Schwierigkeiten kriege, wenn der Upstream-Autor von
Imake auf Autoconf gewechselt ist, oder sowas in der Art.
Hm. Außerdem geht das davon aus, dass debian/rules möglichst
versucht, die vorgesehene Mimik zum Bauen der Pakete zu benutzen.
Also ./configure mit den richtigen Argumenten aufruft, anstatt im
Makefile rumzueditieren, wie vom New Maintainer's Guide
vorgeschlagen. (Dass der New Maintainer's Guide das vorschlägt,
finde ich nicht gut!)
--
A turnip curses Elvis
Kai Großjohann
> Ueberredet. Ich werde meinen Backports in Zukunft eine angepasste
> Versionsnummer verpassen.
Welche? Bzw, wo kann ich nachlesen, welche Versionsnummer ich nehmen
soll? (Ich hab mich noch nicht durch alle Dokus durchgelesen, kann
also einen Hinweis auf die richtige Stelle ganz gut gebrauchen.)
Norbert Tretkowski
>
> > Ueberredet. Ich werde meinen Backports in Zukunft eine angepasste
> > Versionsnummer verpassen.
>
> Welche?
Ich werde mich da Adrians Nummerierung anschliessen.
Uwe Laverenz
> Und was macht man da am besten?
Das ist IMHO eine Frage der persönlichen Vorlieben. Ich würde
unterscheiden zwischen Servern (hohe Lebensdauer) und Workstations mit
brandaktueller Hardware.
Bei den Servern ist es für Debianer keine Frage, bei
Arbeitsplatzrechnern hat man halt die Qual der Wahl: je nach Umfeld und
Anforderung eher konservativ (also Woody) oder eben nicht, wobei mancher
hier auch die Kirschen in Nachbars Garten mag (RedHat in meinem Fall).
cu,
Uwe
Andreas Metzler
> Norbert Tretkowski <tretk...@bzimage.de> writes:
>> Ueberredet. Ich werde meinen Backports in Zukunft eine angepasste
>> Versionsnummer verpassen.
> Welche? Bzw, wo kann ich nachlesen, welche Versionsnummer ich nehmen
> soll? (Ich hab mich noch nicht durch alle Dokus durchgelesen, kann
> also einen Hinweis auf die richtige Stelle ganz gut gebrauchen.)
Hallo!
Gesucht ist etwas das folgende Bedingungen erfuellt:
- kleiner als das Original in unstable (beim dist-upgrade auf unstable
wollen wir schliesslich das offizielle Paket bekommen.)
- groesser als die Versionsnummer des unmittelbar davor erschienen
Pakets.
- eindeutig als Backport von mir erkennbar (Bugreports, dpkg -l)
Als gut geeignet hat sich folgendes erwiesen: Versionsnummer um eins
verringern und ".eindeutiger Kuerzel" anhaengen. Aus 12.4.7-6 machen
wir 12.4.7-5.bunk, oder aus 1.4pre1.6-0.2 1.4pre1.6-0.1.bunk.
Mit
dpkg --compare-versions 12.4.7-5 le 12.4.7-5.bunk && echo "passt."
dpkg --compare-versions 12.4.7-5.bunk le 12.4.7-6 && echo "passt."
laesst sich sehr schoen verifizieren, dass die Anforderungen erfuellt
sind. (Sogar, wenn es davor einen NMU mit Versionsnummer 12.4.7-5.1
gab).
Sollte man in 12.4.7-5.bunk einen Bug im Backport finden, kann man
einfach 12.4.7-5.bunk.1 nachschieben, das ist immer noch kleiner als
12.4.7-6.
Meinereiner verwendet typischerweise "amwoody".
Lesetipp: Debian Policy Kapitel 4.
cu andreas
--
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Adrian Bunk
> Adrian Bunk <bu...@fs.tum.de> writes:
>
> > On Sun, Feb 02, 2003 at 09:28:14PM +0100, Kai Großjohann wrote:
> >
> >>... Und geht man für Backports
> >> besser von dem Stable-Paket aus und benutzt uupdate, um das mit den
> >> neuen Sourcen zu verheiraten, oder geht man besser vom Unstable-Paket
> >> aus und dreht an den Build-Dependencies? Oder vielleicht noch anders?
> >
> > Man geht normalerweise vom Paket in unstable (oder testing) aus.
> > Entweder die build dependencies lassen sich auf stable erfuellen
>
> Du meinst "sind sowieso erfüllt"?
Ja, ich meine "lassen dich durch ein 'apt-get install' innerhalb von
stable erfuellen".
> > oder man muss anfangen sich das Paket genauer anzusehen.
>
> Also, man dreht die Build-Dependencies runter, wenn die Sourcen auch
> mit der alten Version klar kommen, oder man baut auch die neue
> Library aus den Sourcen?
Das haengt vom Einzelfall ab, oft muss man herausfinden warum die build
dependencies so sind wie sie sind - meist haben hohe build dependencies
ja einen Grund.
Wenn z.B. irgendwann einmal debhelper aus unstable ein neueres Perl als
das in stable vorhandene verlangt (war bei potato laestig und kann auch
bei woody passieren) dann musst du dir bei einer build dependency auf
eine neuere Version von debhelper ueberlegen welche Features aus dem
neuen debhelper das Paket verwendest und wie du das emulieren kannst.
> > "uupdate" vom Paket in stable aus duerfte in vielen Faellen deutlich
> > schwieriger sein.
>
> Warum? (Ich will's nicht anzweifeln, sondern nur verstehen.)
>
> Ich als Dummuser hätte jetzt angenommen, dass das debian/-Verzeichnis
> für Stable gut getestet ist, und dass ich mir mit einem Update auf
> die neuen Sourcen eben nur neue Sourcen, nicht aber neue Bugs im
> debian/-Verzeichnis, einhandle.
>...
Im debian/-Verzeichnis brauchst du aber ggf. auch Anpassungen, das kann
an sehr vielen Stellen wie z.B. bei neueren Bibliotheken in einem Paket,
Konvertierungen in Konfigurationsdateien und vielem anderen mehr sein.
Bei nichttrivialen Paketen muss der Debian Maintainer bei neuen
Versionen mehr als ein uupdate machen und genau diese Dinge musst du
dann auch machen. Das alles solltest du natuerlich aehnlich wie der
Debian-Maintainer machen, sonst bekommst du evtl. Probleme falls du
eines Tages auf die offiziellen Pakete aus der naechsten stable upgraden
moechtest.
Bei den Sourcen koennen im alten Debian-Paket beliebig viele Patches
sein und der Debian Maintainer hat evtl. gute Gruende neue Patches in
die neuere Version einzubauen.
> Hm. Außerdem geht das davon aus, dass debian/rules möglichst
> versucht, die vorgesehene Mimik zum Bauen der Pakete zu benutzen.
> Also ./configure mit den richtigen Argumenten aufruft, anstatt im
> Makefile rumzueditieren, wie vom New Maintainer's Guide
> vorgeschlagen. (Dass der New Maintainer's Guide das vorschlägt,
> finde ich nicht gut!)
Im New Maintainers' Guide steht:
<-- snip -->
...
With programs that use GNU autoconf, this will be quite easy. Most
such programs have makefiles that are by default set up to allow
installation into a random subdirectory while keeping in mind that
/usr (for example) is the canonical prefix. When it detects your
program uses autoconf, dh_make will set up commands for doing all this
automatically, so you might as well skip reading this section. But
with other programs, you will most probably have to examine and edit
the Makefiles.
...
<-- snip -->
D.h. wer sich den New Maintainers' Guide durchliest sieht recht
eindeutig dass Aenderungen am Makefile _nicht_ notwendig sind wenn das
Programm GNU autoconf verwendet.
> A turnip curses Elvis
Gruss
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Rainer Ellinger
> Was bring Testing heute einem? Gar nichts.
Wenn ich dann AT in <2003020216...@azure.humbug.org.au> lese:
"As far as glibc's concerned, it's being kept out of testing until it's
working reasonably, which would be decades away, the way things are
going." - dann kann man Testing quasi verbrennen.
Für mich ist das völlig hirnrissig. Es wäre im Moment viel sinnvoller
Testing weitgehend auf dem Stand von Unstable laufen zu lassen. Nur mit
dem Unterschied, dass für die normalen Pakete die übliche Verzögerung
gilt und man als Testing Benutzer nicht täglich mit den neuesten
Maintainer Missgriffen konfrontiert wird.
Sobald aber ein zentrales Paket unzählige andere für Ewigkeiten
blockiert, muss es eben in mangelhaftem Zustand nach Testing. Dann war
auch genug Zeit der Vorwarnung und das BTS enthält ebenfalls schon
Informationen bereit. Eventuell macht der Maintainer bei so wichtigen
Schritten, wie glibc vorher noch ein spezielles Upload mit passenden
Warnhinweisen zu offenen Bugs im Changelog für Leute, die sich auf
apt-listchanges verlassen.
Stattdessen wird getan, als müsse Testing jetzt auf einem Niveau a la
drei Wochen vor dem Release gehalten werden. Ich glaube, die meisten
Leute haben nur keinen Nerv, die kapitalen Hänger aus Unstable, wie
Bash-Bugs, PAM-Updates nach denen kein Login mehr geht oder ähnliche
Scherze mitzumachen. Aber diese Dinge fallen nicht nur in Unstable
sofort auf, sondern sind schon nach ein paar Tagen alle erledigt. Im
Grunde würde es zur Zeit reichen, jedes Paket, dass in Unstable seit 10
Tagen liegt (Bugs hin, Bugs her) nach Testing zu nehmen. Immer noch
besser und nützlicher, wie es als Paketwüste vor sich hin gammeln zu
lassen.
Just my 2ct.
--
Haeufig gestellte Fragen und Antworten (FAQ):