[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reducing allowed Vcs for packaging?



On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
> Hello,

Hi Sean,

> On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote:
> 
> > On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> >> On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
> >>...
> >> > For anything in Debian, the package sources in Debian would not
> >> > disappear when a repository (or salsa) disappears.
> >>
> >> Question as I don't know: is that only the package change that gets uploaded
> >> to the Debian archive, or is there also a place where the (git) history of the
> >> changes leading up to a new upload gets stored?
> >>
> >> To use an analogy: I'd like that not only the 'destination' is preserved, but
> >> also the lead up to the destination.
> >
> > What goes into the Debian archive is based on tarballs and quilt patches.
> > Nothing is stored there except the files you upload.
> 
> This is a matter of perspective.  The fact that dak doesn't store git
> histories and send them out to mirrors is an implementation detail, to
> me.  salsa and dgit-repos are both just as significant Debian archives,
> even if they're not what we refer to when we write "Debian archive".

for the contents of packages in the archive the ftp team requires that 
everything is in the preferred form of modification.

It is therefore surprising that you as member of the ftp team declare 
that there is no requirement at all that the packages themselves that 
get uploaded to the archive are in the preferred form of modification
as long as the preferred form of modification is in salsa.

Maintainers are now permitted to clone the upstream git tree, take one 
commit as upstream, work on top of that, and then upload this without 
the kludge of pristine-tar or restrictions due to quilt.

Formats 1.0 or 3.0 (native) will be the natural formats generated for
the Debian archive.

Format 3.0 (quilt) will be another option, where a generated tarball is 
uploaded as upstream source (as is already required by the ftp team for 
repacks) plus one debian/patches/debian.patch containing all changes to 
the upstream sources.

Generating one quilt patch per commit that changes the upstream sources
would not always be technically possible due to limitations of quilt.

> Sean Whitton

cu
Adrian


Reply to: