Re: [RFC] General Resolution to deploy tag2upload
Hi,
On Wed, 2024-06-19 at 08:39 -0700, Russ Allbery wrote:
> Ansgar 🙀 <ansgar@43-1.org> writes:
> > People could just move to native packages if they do that: that also
> > works for changes to binary files, no longer requires synthesizing
> > patches and thus brings the Debian source package closer to the Git
> > state. This is also easier to compare to maintainers' repository.
>
> Sure, we could tell people to use 3.0 (native) for everything with Debian
> changes to the upstream source and stop trying to use 3.0 (quilt). You're
> not the first person to make that suggestion, and it has some real merit
> for simplicity of representation of source packages.
Yes, it is both simpler and allows for more integrity guarantees.
Other ideas like waldi's 3.0 (gitarchive) also go in that direction.
> But that means that
> we now can't share the .orig.tar.gz file between Debian package releases,
> which has implications for the size of the archive.
I'm not sure it changes much given we have arch:any binaries and debug
symbols for all packages these days. Uploads being large is also not a
problem as tag2upload does not have to be content with a possibly low
bandwidth end-user connection.
For repeated downloads one could use Git to get incremental updates and
use only the integrity information from the archive (if desired).
I'm interested what other ftp-masters prefer when considering a trade
off between space and additional integrity guarantees here. I have a
preference for the integrity side.
> It breaks tools to
> extract the patches from a 3.0 (quilt) package. And, based on previous
> debian-devel discussions of exactly this, people have a lot of strong
> opinions about not using 3.0 (native) when there is an upstream.
We break some things either way. If people want to extract patches in
that format, they can still generate them from the Git repository?
> tag2upload is intended to work with what package maintainers are doing
> today as much as reasonably possible, not to force them to use different
> workflows and source package representations.
Well, it doesn't change what package maintainers do as the purpose of
tag2upload is that package maintainers don't have to think about source
package representation? So changing those should not affect maintainers
much?
It's far more consistent with treating source packages as a build
artifact to not do complicated transformations if that can be
avoided...
Ansgar
Reply to: