Re: [RFC] General Resolution to deploy tag2upload
Hi
On Wed, Jun 19, 2024 at 11:18:36AM -0700, Russ Allbery wrote:
> > Other ideas like waldi's 3.0 (gitarchive) also go in that direction.
>
> Similarly, I'm not sure a source package based on Git avoids the need for
> a source package build system. There are a ton of ways that maintainers
> store things in Git, and I'm not sure it makes sense to upload all of
> those as-is.
Do you have some examples of weird things?
> The things that break are slightly different, but, for
> instance, some maintainers do not want the upstream source in the same
> branch as their Debian packaging files. You may have to add quite a lot
> of unwanted complexity to 3.0 (gitarchive) to represent those cases.
Well, I already thought about something like that. The question is
just: can we boil that down to a manageable number?
For example the Linux kernel just got the debian directory in git, but
not the source. We in Debian still maintain patches, but other
distributions just switched to a fork of upstream Linux with their
changes on top.
A possible impelementation would use one or more submodules to reference
the real source. The implementation for the source format just needs to
expand those submodules for "git archive". This creates then a
reproducible result.
Okay, this still have the problem that parts of the source is actually
generated. But we can also integrate such a step into the source format
if we want. So in the end you are not doing "commit; push" but
"dpkg-source --commit", which prepares, commits the changes, tags and
push or so.
> Or
> reintroduce a source package build step, in which case we're back to where
> we started.
And that's where the problem lies. We make this either declarative and
reproducible. Or we make it touring complete.
> > 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.
>
> I think it's also a trade off in supported workflows. If we start telling
> people exactly how they have to use Git to work on Debian packages, we can
> simplify a lot of things, but wow do I ever not want to open that can of
> worms. Every time we open it on debian-devel, it's a giant mess. (Even
> more than this thread!)
But why would tag2upload need to support them? It is something new, it
can tell people: we support the following, use it or not.
IMHO it is one of the problem of Debian that we fail to move forward.
Bastian
--
Sometimes a feeling is all we humans have to go on.
-- Kirk, "A Taste of Armageddon", stardate 3193.9
Reply to: