Ansgar π writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> If we are talking about hypothetical ways upstream might nudge you
> into:No, that's not what Phil's talking about. Phil's talking about, for example, Russ's git-debrebase workflow, where the git is treesame to the source package *until Russ needs to diverge from upstream*. No sensible maintainer is going to adopt a workflow that falls apart the first time you want to carry a patch. There are other more subtle issues that might arise, depending on workflow, upstream practices, etc. etc. One of the things that we tag2upload proponents seem to be having difficulty getting across is just how complicated and diverse our existing workflows in Debian are. It's easy to imagine that everyone is doing roughly the same as you. But, they *really* aren't. But ... > there is a large territory that requires arbitrary code execution > as build time (say to instatiate d/control from a template) which > neither proposal for tag2upload allows. There is no reason in principle why tag2upload couldn't support templating of d/control, provided that the templating doesn't involve executing arbitrary code and doesn't involve giant globs of language-specific processing. We'd want to define a templating arrangement that would be useable by multiple of the monorepo-based packaging teams. IHNI if that is feasible or not but it doesn't seem inherently impossible. This is an example of the kind of advancement that is enabled, at least theoretically, by centralising and standardising the building of source packages. (Currently, for those team monorepos, what's in the Debian archive *definitely* isn't the source code, IMO. It's the output of a mysterous transformation which takes as one of its inputs a git tree that - if you're lucky - is somewhere on salsa.) Ian. -- Ian Jackson <[email protected]> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
