Groups > de.comp.os.unix.linux.misc > #129713

Re: git

From	Tim Landscheidt <tim@tim-landscheidt.de>
Newsgroups	de.comp.os.unix.linux.misc
Subject	Re: git
Date	2023-03-25 23:59 +0000
Organization	https://www.tim-landscheidt.de/
Message-ID	<871qlce62e.fsf@vagabond.tim-landscheidt.de> (permalink)
References	(6 earlier) <slrnu1mfm0.irg9.martin@lounge.imp.fu-berlin.de> <6esfdvtkq0.fsf@th-dorner.de> <slrnu1t0g2.118vr.martin@lounge.imp.fu-berlin.de> <tvmgr2.4ag.1@stefan.msgid.phost.de> <tvmmgq$10pm5$1@news1.tnib.de>

Show all headers | View raw

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

> […]

> Wo wir gerade bei solchen Debian-Grundlagen sind: Die Debian-Changes
> an den Upstreamsourcen liegen als quilt-Patches in debian/patches und
> werden beim Bau angewendet und danach wieder unapplied, dsa machen
> aber die Builtools automatisch und eigentlich ist der Prozess ganz
> flauschig. Das ganze nennt sich "Source-Format 3.0 (quilt)".

> Es gibt immer mal wieder Bewegungen, sich diese quilt-Zwischenstufe zu
> sparen und die Änderungen am Upstream direkt mit der Versionskontrolle
> mitzuführen ("Source-Format 3.0 (git)"); ich habe mir immer mal wieder
> vorgenommen, das mit einem meiner Pakete mal auszuprobieren es aber
> bisher noch nicht getan.

Sowohl bei dem ersteren als gerade auch bei dem letzteren
schüttelt es mich immer gewaltig. Ich bin mit RPMs „pristine
sources“ aufgewachsen, und schon die Vorstellung, dass man
den Tarball neu baut, tut mir physisch weh.

Aber der Gedanke, dass sowohl die Prüfung der Echtheit der
Ursprungssoftware nicht mit einem Blick erledigt ist, als
auch, dass wichtige Patches bei einem Git-Rebase/-Merge her-
unterfallen könnten, weil ein gutmeinender Maintainer auf
Gits Automatik vertraut statt ein sehr genaues Auge darauf
zu werfen – *brrr*.

> Und dann gibt es noch einen Schritt weiter namens dgit, wo man gar
> kein Source-Paket mehr baut und hochlädt, sondern einen Tag signiert
> und pusht und die Debian-Infrastruktur dann Source- und Binärpaket
> selbst extrahiert und baut. Das klingt auf den ersten Blick gar nicht
> schlecht, aber die Art wie aggressiv der Autor Ian Jackson seine Idee
> pusht ist mir inhärent unsympathisch. Ich denke, gute Lösungen
> verbreiten sich von selbst ohne dass man bei jeder Gelegenheit aus dem
> Busch springen und für seine Idee Werbung machen muss.

Ich glaube, das läuft prinzipiell bei Fedora ja genauso. Das
ist auch einer der Punkte, die mich bei Debian häufig ver-
zweifelt ließen (ich kann zu dem aktuellen Stand nichts sa-
gen): Jedes Paket hatte nicht nur sein eigenes „Repository“,
sondern auch, wie man aus diesem Repository ein Source-Paket
baut, war prinzipiell jedem Paketmaintainer selbst überlas-
sen. Das ist bei Fedora halt idiotensicher: Es gibt eine
zentrale Instanz und exakt einen Weg.

Die beste Erfindung hat Debian jedoch: „Standards-Version“.
Fedoras Idee, dass jeder Maintainer bei einer Änderung der
Packaging Guidelines sofort alle seine Pakete prüft und ge-
gebenenfalls aktualisiert …

Tim

Thread

Re: git Martin Vaeth <martin@mvath.de> - 2023-03-12 15:15 +0000
  Re: git Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-03-12 15:56 +0000
    Re: git Thomas Hochstein <thh@thh.name> - 2023-03-12 18:07 +0100
      Re: git Martin Vaeth <martin@mvath.de> - 2023-03-13 01:41 +0000
        Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 17:01 +0100
        Re: git Thomas Hochstein <thh@thh.name> - 2023-03-18 20:24 +0100
          Re: git Martin Vaeth <martin@mvath.de> - 2023-03-21 16:09 +0000
            Re: git Thomas Dorner <dcoulm230321.dorner@spamgourmet.com> - 2023-03-21 19:09 +0100
              Re: git Martin Vaeth <martin@mvath.de> - 2023-03-22 17:45 +0000
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-22 18:50 +0000
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-25 04:38 +0000
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-05 13:08 +0000
                Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-05 19:40 +0200
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-06 09:41 +0200
                Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-07 08:47 +0200
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-10 09:02 +0200
                Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-04-10 09:46 +0200
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-10 11:35 +0200
                Re: git Tim Landscheidt <tim@tim-landscheidt.de> - 2023-04-14 13:56 +0000
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-06 09:35 +0200
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-06 20:34 +0000
                Re: git Thomas Dorner <dcoulm230323.dorner@spamgourmet.com> - 2023-03-23 18:56 +0100
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-25 05:09 +0000
                Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-25 10:02 +0100
                Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-25 11:22 +0100
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-26 16:22 +0000
                Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-27 18:10 +0200
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-25 12:39 +0100
                Re: git Tim Landscheidt <tim@tim-landscheidt.de> - 2023-03-25 23:59 +0000
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-26 09:04 +0200
                Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-26 12:59 +0200
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-26 13:18 +0200
                Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-26 10:41 +0200
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-05 12:42 +0000
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-04-14 22:17 +0200
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-15 07:50 +0000
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-18 07:28 +0000
                Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-04-18 18:06 +0000
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-04-22 18:06 +0000
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 22:26 +0200
                Re: git Christian Garbs <mitch@cgarbs.de> - 2023-07-25 19:45 +0000
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-08-06 13:45 +0200
                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 21:26 +0200
                Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-04-15 12:15 +0000
                Re: git Martin Vaeth <martin@mvath.de> - 2023-03-26 17:39 +0000
            Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-21 21:02 +0000
            Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-22 00:56 +0100
              Re: git Martin Vaeth <martin@mvath.de> - 2023-03-22 17:14 +0000
    Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 18:51 +0100
      Re: git Martin Vaeth <martin@mvath.de> - 2023-03-13 01:46 +0000
        Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 17:02 +0100
          Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-18 11:23 +0100
            Re: git Laurenz Trossel <me@example.invalid> - 2023-03-18 12:18 +0000
            Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-19 17:15 +0100
          Re: git Martin Vaeth <martin@mvath.de> - 2023-03-21 14:57 +0000

csiph-web