Re: Reducing allowed Vcs for packaging?
On March 4, 2023 5:25:35 PM UTC, Adrian Bunk <bunk@debian.org> wrote:
>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.
Putting something in a git repository doesn't make a particular file more or less the preferred form of modification. It's the same form. IMO you are conflating two separate concepts here. I don't find Sean's perspective at all surprising.
Scott K
Reply to: