Re: Wofür ist testing gut?
On Mon, Feb 03, 2003 at 09:42:15AM +0100, Kai Großjohann wrote:
> Adrian Bunk <bunk@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
Reply to: